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内 容 简 介 

本 书 从 消息 中 间 件 的 概念 和 RabbitMQ 的 历史 切入 ， 主 要 阐述 RabbitMQ 的 安装 、 使 用 、 配 置 、 管 理 、 运 
维 、 原 理 、 扩 展 等 方面 的 细节 。 本 书 大 致 可 以 分 为 基础 篇 、. 进 阶 篇 和 高 阶 篇 三 个 部 分 。 基 础 篇 首先 介绍 RabbitMQ 
的 基本 安装 及 使 用 方式 ,方便 零 基 础 的 读者 以 最 舒适 的 方式 融入 到 RabbitMQ 之 中 。 其 次 介绍 RabbitMQ 的 基 
本 概念 ， 包 括 生产 者 、 消 费 者、 交换 器 、 队 列 、 绑 定 等 。 之 后 通过 Java 语言 讲述 了 客户 端 如 何 与 RabbitMQ 
建立 (关闭 ) 连接 、 声明 (删除 ) 交换 器 、 队 列 、 绑 定 关系 ,以 及 如 何 发 送 和 消费 消息 等 。 进 阶 篇 讲述 RabbitMQ 
的 TTL、 死 信 、 延 迟 队 列 、 优 先 级 队列 、RPC、 消 息 持 久 化 、 生 产 端 和 消费 端的 消息 确认 机 制 等 内 容 ， 以 期 
读者 能 够 掌握 RabbitMQ 的 使 用 精髓 。 本 书 中 间 篇 幅 主 要 从 RabbitMQ 的 管理 、 配 置 、 运 维 这 三 个 角度 来 为 读 
者 提供 帮助 文档 及 解决 问题 的 思路 。 高 阶 篇 主要 阅 述 RabbitMQ 的 存储 机 制 、 流 控 及 镜像 队列 的 原理 ， 深 入 
地 讲述 RabbitMQ 的 一 些 实现 细节 , 便于 读者 加 深 对 RabbitMQ 的 理解 。 本 书 还 涉及 网 络 分 区 的 概念 ， 此 内 容 
可 称 为 魔鬼 篇 ， 需 要 掌握 前 面 的 所 有 内 容 才 可 理解 其 中 的 门道 。 本 书 最 后 讲述 的 是 RabbitMQ 的 一 些 扩展 内 
容 及 附录 ， 供 读者 参考 之 用 。 

本 书 既 可 供 初学 者 学 习 ， 帮 助 读者 了 解 RabbitMQ 的 具体 细节 及 使 用 方式 、 原 理 等 ， 也 可 供 相关 开发 、 测 试 
及 运 维和 人 员 参 考 ， 给 日 常 工作 带 来 启发 。 | 
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初 识 RabbitMQ 时 ， 我 在 网 上 搜寻 了 大 量 的 相关 资料 以 求 自己 能 够 快速 地 理解 它 ， 但 是 这 些 资 
料 零 零散 散 而 又 良 劳 不 齐 。 后 来 又 寄 希 望 于 RabbitMQ 的 相关 书籍 ， 或 许 是 它们 都 非 出 自 国 人 之 手 ， 
里 面 的 陈述 逻辑 和 案例 描述 都 不 太 符 合 我 自己 的 思维 习惯 。 最 后 选择 从 头 开始 自 研 RabbitMQ, 包括 
阅读 相关 源码 、 翻 阅 官网 的 资料 以 及 进行 大 量 的 实验 等 。 


平时 我 也 有 写 博客 的 习惯 ,通常 在 工作 中 过 到 问题 时 会 结合 所 学 的 知识 整理 成 文 。 随 着 一 篇 篇 
的 积累 ， 也 有 好 几 十 篇 的 内 容 ， 渐 渐 地 也 就 有 了 编撰 成 书 的 想法 。 


本 书 动笔 之 时 我 曾 信心 满 满 ， 以 为 能 够 顺 其 自然 地 完成 这 本 书 ， 但 是 写 到 四 分 之 一 时 ， 发 现 并 
没有 想象 中 的 那么 简单 。 怎 样 才能 让 理解 领悟 汇聚 成 通俗 易 懂 的 文字 表达 ? 怎样 才能 让 书 中 内 容 前 
后 贯通 、 由 浅 入 深 地 图 述 ? 有 些 时 候 可 能 知道 怎样 做 、 为 什么 这 么 做 ， 而 没有 反思 其 他 情形 能 不 能 
做 、 怎 样 做 。 为 了 解决 这 些 问题 ， 我 会 反复 对 书 中 的 内 容 进 行 迭 代 ， 对 某 些 模糊 的 知识 点 深耕 再 深 
耕 ， 对 某 些 案例 场景 进行 反复 的 测试 ， 不 断 地 完善 。 


在 本 书 编写 之 时 ， 我 常常 回想 当初 作为 小 白 之 时 迫切 地 希望 能 够 了 解 哪些 内 容 ， 这 些 内 容 又 希 
望 以 怎样 的 形式 展现 。 所 以 本 书 前 面 几 章 的 内 容 基 本 上 是 站 在 一 个 小 白 的 视角 来 为 读者 做 一 个 细腻 
的 讲解 ， 相 信 读 者 在 阅读 完 这 些 内 容 之 后 能 够 具备 合理 使 用 RabbitMQ 的 能 力 。 在 后 面 的 章节 中 知 
识 点 会 慢 慢 地 深入 ， 每 阅读 一 章 的 内 容 都 会 对 RabbitMQ 有 一 个 更 加 深刻 的 认 知 。 


本 书 中 的 所 有 内 容 都 具备 理论 基础 并 全 部 实践 过 ， 书 中 的 内 容 也 是 我 在 工作 中 的 实践 积累 ， 希 
望 本 书 能 够 让 初学 者 对 RabbitMQ 有 一 个 全 面 的 认 知 ， 也 希望 有 相关 经 验 的 人 士 可 以 从 本 书 中 得 到 
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一 些 启发 ， 汲 取 一 些 经 验 。 
内 容 大 纲 


本 书 共 11 章 , 前 后 章节 都 有 相关 的 联系 , 基本 上 按照 由 浅 入 深 、 由 表 及 里 的 层次 逐 层 进行 讲解 。 
如 果 读 者 对 其 中 的 某 些 内 容 已 经 掌握 ， 可 以 选择 跳 过 而 翻阅 后 面 的 内 容 ， 不 过 还 是 建议 读者 按照 先 
后 顺序 进行 阅读 。 

第 1 章 主要 针对 消息 中 间 件 做 一 个 摘要 性 介绍 ， 包 括 什么 是 消息 中 间 件 、 消 息 中 间 件 的 作用 及 
特点 等 。 之 后 引入 RabbitMQ， 对 其 历史 和 相关 特点 做 一 个 简要 概述 。 本 章 最 后 介绍 RabbitMQ 的 安 
装 及 生产 、 消 费 的 使 用 示例 。 

第 2 章 主要 讲述 RabbitMQ 的 入 门 知识 ， 包 括 生 产 者 、 消 费 者 、 队 列 、 交 换 器 、 路 由 键 、 绑 定 、 
连接 及 信道 等 基本 术语 。 本 章 还 阐述 了 RabbitMQ 与 AMQP 协议 的 对 应 关系 。 

第 3 章 主要 介绍 RabbitMQ 客户 端 开发 的 简单 使 用 ， 按 照 一 个 生命 周期 对 连接 、 创 建 、 生 产 、 
消费 及 关闭 等 几 个 方面 进行 宏观 的 介绍 。 

第 4 章 介 绍 数据 可 靠 性 的 一 些 细 节 ， 并 展示 RabbitMQ 的 几 种 已 具备 或 衍生 的 高 级 特性 ， 包 括 
TTL、 死 信 队 列 、 延 迟 队 列 、 优 先 级 队列 、RPC 等 ， 这 些 功 能 在 实际 使 用 中 可 以 让 某 些 应 用 的 实现 
变 得 事半功倍 。 

第 5 章 主要 围绕 RabbitMQ 管理 这 个 主题 展开 ， 包 括 多 租户 、 权 限 、 用 户 、 应 用 和 集群 管理 、 
服务 端 状态 等 方面 ， 并 且 从 侧面 讲述 rabbitmqctl 工具 和 rabbitmq management 插件 的 使 用 。 

第 6 章 主要 讲述 RabbitMQ 的 配置 ， 以 此 可 以 通过 环境 变量 、 配 置 文 件 、 运 行 时 参数 (和 策略 ) 
等 三 种 方式 来 定制 化 相应 的 服务 。 

第 7 章 主 要 围绕 运 维 层面 展开 论述 ， 主 要 包括 集群 搭建 、 日 志 查 看 、 故 障 恢复 、 集 群 迁移 、 集 
群 监控 这 几 个 方面 。 

第 8 章 主 要 讲述 Federation 和 Shovel 这 两 个 插件 的 使 用 、 细 节 及 相关 原理 。 区 别 于 第 7 章 中 集 
群 的 部 署 方式 ，Federation 和 Shovel 可 以 部 署 在 广域网 中 ， 为 RabbitMQ 提供 更 广泛 的 应 用 空间 。 

第 9 章 介 绍 RabbitMQ 相关 的 一 些 原 理 ， 主 要 内 容 包括 RabbitMQ 存储 机 制 、 磁 盘 和 内 存 告警 、 
流 控 机 制 、 镜 像 队 列 。 了 解 这 些 实现 的 细节 及 原理 十 分 必要 ， 它 们 可 以 让 读者 在 遇 到 问题 时 能 够 透 
过 现象 看 本 质 。 
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第 10 章 主要 围绕 网 络 分 区 进行 展开 ， 具 体 阐述 网 络 分 区 的 意义 ， 如 何 查 看 和 处 理 网 络 分 区 ， 以 
及 网 络 分 区 所 带 来 的 影响 。 


第 11 章 主要 探讨 RabbitMQ 的 两 个 扩展 内 容 : 消息 追踪 及 负载 均衡 。 消 息 追 踪 可 以 有 效 地 定位 
消息 丢失 的 问题 。 负 载 均 衡 本 身 属 于 运 维 层 面 ， 但 是 负载 均衡 一 般 需 要 借助 第 三 方 的 工具 
——HAProxy. LVS 等 实现 ， 故 本 书 将 其 视 为 扩展 内 容 。 


读者 讨论 
由 于 作者 水 平 有 限 ， 书 中 难免 有 错误 之 处 。 在 本 书 出 版 后 的 任何 时 间 ， 若 你 对 本 书 有 任何 的 疑问 ， 


都 可 以 通过 zhuzhonghuaideal@qqcom 发 送 邮 件 给 作者 ， 也 可 以 到 作者 的 个 人 博客 
http://blog.csdn.net/u013256816 留言 ， 向 作者 阐述 你 的 建议 和 想法 。 如 若 收 到 相关 信息 ， 作 者 都 会 回复 。 
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轻松 注册 成 为 博文 视点 社区 用 户 (www.broadview.com.cn)， 扫 码 直 达 本 书页 面 。 
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第 1 章 
RabbitMQ 简介 


RabbitMQ 是 目前 非常 热门 的 一 款 消息 中 间 件 , 不管 是 互联 网 行业 还 是 传统 行业 都 在 大 量 
地 使 用 。RabbitMQ 凭借 其 高 可 靠 、 易 扩展 、 高 可 用 及 丰富 的 功能 特性 受到 越 来 越 多 企业 的 青 
睐 。 作 为 一 个 合格 的 开发 者 ， 有 必要 深入 地 了 解 RabbitMQ 的 相关 知识 ,为 自己 的 职业 生涯 添 
砖 加 瓦 。 


RabbitMQ 实战 指南 /——— 


11 什么 是 消息 中 间 件 


iE. (Message) 是 指 在 应 用 间 传 送 的 数据 。 消 息 可 以 非常 简单 ， 比 如 只 包含 文本 字符 串 、 
JSON 等 ， 也 可 以 很 复杂 ， 比 如 内 髓 对 象 。 


消息 队列 中 间 件 (Message Queue Middleware, FKA MQ) 是 指 利用 高 效 可 靠 的 消息 传递 
机 制 进行 与 平台 无 关 的 数据 交流 ， 并 基于 数据 通信 来 进行 分 布 式 系 统 的 集成 。 通 过 提供 消息 传 
递 和 消息 排队 模型 ， 它 可 以 在 分 布 式 环境 下 扩展 进程 间 的 通信 。 


消息 队列 中 间 件 ， 也 可 以 称 为 消息 队列 或 者 消息 中 间 件 。 它 一 般 有 两 种 传递 模式 ， 点 对 点 
(P2P, Point-to-Point) 模式 和 发 布 /订阅 (Pub/Sub) 模式 。 点 对 点 模式 是 基于 队列 的 ， 消 息 生 产 
者 发 送 消息 到 队列 , 消息 消费 者 从 队列 中 接收 消息 , 队列 的 存在 使 得 消息 的 异步 传输 成 为 可 能 。 
发 布 订阅 模式 定义 了 如 何 向 一 个 内 容 节点 发 布 和 订阅 消息 ， 这 个 内 容 节点 称 为 主题 (topic)， 主 
题 可 以 认为 是 消息 传递 的 中 介 ， 消 息 发 布 者 将 消息 发 布 到 某 个 主题 ， 而 消息 订阅 者 则 从 主题 中 
订阅 消息 。 主 题 使 得 消息 的 订阅 者 与 消息 的 发 布 者 互相 保持 独立 ， 不 需要 进行 接触 即 可 保证 消 
息 的 传递 ， 发 布 /订阅 模式 在 消息 的 一 对 多 广播 时 采用 。 

目前 开源 的 消息 中 间 件 有 很 多 ， 比 较 主流 的 有 RabbitMQ、Kafka、ActiveMQ、RocketMQ 
等 。 面 向 消息 的 中 间 件 (简称 为 MOM，Message Oriented Middleware) 提供 了 以 松散 耦合 的 灵 
活 方 式 集成 应 用 程序 的 一 种 机 制 。 它 们 提供 了 基于 存储 和 转发 的 应 用 程序 之 间 的 异步 数据 发 送 ， 
即 应 用 程序 彼此 不 直接 通信 ， 而 是 与 作为 中 介 的 消息 中 间 件 通信 。 消 息 中 间 件 提供 了 有 保证 的 
消息 发 送 ， 应 用 程序 开发 人 员 无 须 了 解 远程 过 程 调 用 (RPC) 和 网 络 通信 协议 的 细节 。 


消息 中 间 件 适用 于 需要 可 靠 的 数据 传送 的 分 布 式 环境 。 采 用 消息 中 间 件 的 系统 中 ， 不 同 的 
对 象 之 间 通 过 传递 消息 来 激活 对 方 的 事件 ， 以 完成 相应 的 操作 。 发 送 者 将 消息 发 送 给 消息 服务 
器 ， 消 息 服务 器 将 消息 存放 在 若干 队列 中 ， 在 合适 的 时 候 再 将 消息 转发 给 接收 者 。 消 息 中 间 件 
能 在 不 同 平台 之 间 通 信 ， 它 常 被 用 来 屏蔽 各 种 平台 及 协议 之 间 的 特性 ， 实 现 应 用 程序 之 间 的 协 
同 ， 其 优点 在 于 能 够 在 客户 和 服务 器 之 间 提 供 同 步 和 异步 的 连接 ， 并 且 在 任何 时 刻 都 可 以 将 消 
息 进行 传送 或 者 存储 转发 ， 这 也 是 它 比 远程 过 程 调用 更 进步 的 原因 。 


举例 说 明 ， 如 图 1-1 所 示 ， 应 用 程序 A 与 应 用 程序 B 通过 使 用 消息 中 间 件 的 应 用 程序 编程 
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接口 (API，Application Program Interface) 发 送 消息 来 进行 通信 。 


Application Program Interface 













消息 中 间 件 
(Message Oriented Middleware) 






图 1-1 应 用 通过 消息 中 间 件 进行 通信 


消息 中 间 件 将 消息 路 由 给 应 用 程序 B， 这 样 消息 就 可 存在 于 完全 不 同 的 计算 机 上 。 消 息 中 
间 件 负责 处 理 网 络 通信 ， 如 果 网 络 连接 不 可 用 ， 消 息 中 间 件 会 存储 消息 ， 直 到 连接 变 得 可 用 ， 
再 将 消息 转发 给 应 用 程序 B。 灵 活性 的 另 一 方面 体现 在 ， 当 应 用 程序 A 发 送 其 消息 时 ， 应 用 程 
È B 甚至 可 以 处 于 不 运行 状态 ,消息 中 间 件 将 保留 这 份 消息 ， 直 到 应 用 程序 B 开始 执行 并 消费 
消息 , 这 样 还 防止 了 应 用 程序 A 因为 等 待 应 用 程序 B 消费 消息 而 出 现 阻 塞 。 这 种 异步 通信 方式 
要 求 应 用 程序 的 设计 与 现在 大 多 数 应 用 不 同 。 不 过 对 于 时 间 无 关 或 并 行 处 理 的 场景 ， 它 可 能 是 
一 个 极其 有 用 的 方法 。 


12 “消息 中 间 件 的 作用 





消息 中 间 件 凭借 其 独到 的 特性 ， 在 不 同 的 应 用 场景 下 可 以 展现 不 同 的 作用 。 总 的 来 说 ， 消 
息 中 间 件 的 作用 可 以 概括 如 下 。 

in: 在 项 目 启动 之 初 来 预 测 将 来 会 碰 到 什么 需求 是 极其 困难 的 。 消 息 中 间 件 在 处 理 过 程 
中 间 插 入 了 一 个 隐 含 的 、 基 于 数据 的 接口 层 ， 两 边 的 处 理 过 程 都 要 实现 这 一 接口 ， 这 人 允许 你 独 
立地 扩展 或 修改 两 边 的 处 理 过 程 ， 只 要 确保 它们 遵守 同样 的 接口 约束 即 可 。 
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NR (FR): 有 些 情 况 下 ， 处 理 数 据 的 过 程 会 失败 。 消 息 中 间 件 可 以 把 数据 进行 持久 化 直 
到 它们 已 经 被 完全 处 理 ， 通 过 这 一 方式 规避 了 数据 丢失 风险 。 在 把 一 个 消息 从 消息 中 间 件 中 删 
除 之 前 ， 需 要 你 的 处 理 系统 明确 地 指出 该 消息 已 经 被 处 理 完成 ， 从 而 确保 你 的 数据 被 安全 地 保 
存 直 到 你 使 用 完毕 。 


扩展 性 : 因为 消息 中 间 件 解 看 了 应 用 的 处 理 过 程 ， 所 以 提高 消息 入 队 和 处 理 的 效率 是 很 容 
易 的 ， 只 要 另外 增加 处 理 过 程 即 可 ， 不 需要 改变 代码 ， 也 不 需要 调节 参数 。 

削 峰 : 在 访问 量 剧 增 的 情况 下 ， 应 用 仍然 需要 继续 发 挥 作 用 ， 但 是 这 样 的 突 发 流量 并 不 常 
见 。 如 果 以 能 处 理 这 类 峰值 为 标准 而 投入 资源 ， 无 疑 是 巨大 的 浪费 。 使 用 消息 中 间 件 能 够 使 关 
键 组件 支 撑 突 发 访问 压力 ， 不 会 因为 突 发 的 超 负 荷 请 求 而 完全 月 省 。 

可 恢复 性 : 当 系 统一 部 分 组 件 失 效 时 ， 不 会 影响 到 整个 系统 。 消 息 中 间 件 降低 了 进程 间 的 
耦合 度 ， 所 以 即使 一 个 处 理 消息 的 进程 挂 掉 ， 加 入 消息 中 间 件 中 的 消息 仍然 可 以 在 系统 恢复 后 
进行 处 理 。 

顺序 保证 : 在 大 多 数 使 用 场景 下 ， 数 据 处 理 的 顺序 很 重要 ， 大 部 分 消息 中 间 件 支持 一 定 程 
度 上 的 顺序 性 。 

缓冲 : 在 任何 重要 的 系统 中 ， 都 会 存在 需要 不 同 处 理 时 间 的 元 素 。 消 息 中 间 件 通过 一 个 组 
冲 层 来 帮助 任务 最 高 效率 地 执行 ， 写 入 消息 中 间 件 的 处 理会 尽 可 能 快速 。 该 缓冲 层 有 助 于 控制 
和 优化 数据 流 经 过 系统 的 速度 。 

异步 通信 :在 很 多 时 候 应 用 不 想 也 不 需要 立即 处 理 消息 ,消息 中 间 件 提供 了 异步 处 理 机 制 ， 
允许 应 用 把 一 些 消 息 放 入 消息 中 间 件 中 ， 但 并 不 立即 处 理 它 ， 在 之 后 需要 的 时 候 再 慢 慢 处 理 。 


1.3 RabbitMQ 的 起 源 


RabbitMQ 是 采用 Erlang 语言 实现 AMQP (Advanced Message Queuing Protocol， 高 级 消息 
队列 协议 ) 的 消息 中 间 件 ， 它 最 初 起 源 于 金融 系统 ， 用 于 在 分 布 式 系统 中 存储 转发 消息 。 


在 此 之 前 ,有 一 些 消息 中 间 件 的 商业 实现 , 比如 微软 的 MSMQ(MicroSoft Message Queue)、 
IBM 的 WebSphere 等 。 由 于 高 昂 的 价格 ， 一般 只 应 用 于 大 型 组 织 机 构 ， 它 们 需要 可 靠 性 、 解 看 
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及 实时 消息 通信 的 功能 。 由 于 商业 壁垒 ， 商 业 MQ 供应 商 想 要 解决 应 用 互通 的 问题 ， 而 不 是 去 
创建 标准 来 实现 不 同 的 MQ 产品 间 的 互通 ， 或 者 允许 应 用 程序 更 改 MQ 平台 。 


为 了 打破 这 个 壁垒 ， 同 时 为 了 能 够 让 消息 在 各 个 消息 队列 平台 间 互 融 互 通 ，JMS (Java 
Message Service) 应 运 而 生 。JMS 试图 通过 提供 公共 Java API 的 方式 ， 隐 藏 单独 MQ 产品 供应 
商 提供 的 实际 接口 ， 从 而 跨越 了 壁垒 ， 以 及 解决 了 互通 问题 。 从 技术 上 讲 ，Java 应 用 程序 只 需 
针对 JMS API 编程 ， 选 择 合适 的 MQ 驱动 即 可 ，JMS 会 打 理 好 其 他 部 分 。ActiveMQ 就 是 JMS 
的 一 种 实现 。 不 过 尝试 使 用 单独 标准 化 接口 来 胶合 众多 不 同 的 接口 ， 最 终 会 暴露 出 问题 ， 使 得 
应 用 程序 变 得 更 加 脆弱 。 所 以 急需 一 种 新 的 消息 通信 标准 化 方案 。 


TE 2006 £6 H, H Cisco. Redhat, iMatix 等 联合 制定 了 AMQP 的 公开 标准 ， 由 此 AMQP 
登 上 了 历史 的 舞台 。 它 是 应 用 层 协议 的 一 个 开放 标准 ， 以 解决 众多 消息 中 间 件 的 需求 和 拓扑 结 
构 问 题 。 它 为 面向 消息 的 中 间 件 设计 ， 基 于 此 协议 的 客户 端 与 消息 中 间 件 可 传递 消息 ， 并 不 受 
产品 、 开 发 语言 等 条 件 的 限制 。 

RabbitMQ 最 初版 本 实现 了 AMQP 的 一 个 关键 特性 : 使 用 协议 本 身 就 可 以 对 队列 和 交换 器 
(Exchange) 这 样 的 资源 进行 配置 。 对 于 商业 MQ 供应 商 来 说 , 资源 配置 需要 通过 管理 终端 的 特 
定 工 具 才 能 完成 。 RabbitMQ 的 资源 配置 能 力 使 其 成 为 构建 分 布 式 应 用 的 最 完美 的 通信 总 线 , 特 
别 有 助 于 充分 利用 基于 云 的 资源 和 进行 快速 开发 。 

RabbitMQ 是 由 RabbitMQ Technologies Ltd 开发 并 且 提 供 商 业 支 持 的 。 取 Rabbit 这 样 一 个 
名 字 , 是 因为 兔子 行动 非常 迅速 且 繁 殖 起 来 非常 疯狂 ，RabbitMQ 的 开创 者 认为 以 此 命名 这 个 分 
布 式 软件 再 合适 不 过 了 。RabbitMQ Technologies Ltd 在 2010 年 4 月 被 SpringSource (VMWare 
的 一 个 部 门 ) 收购 , 在 2013 年 5 月 并 入 Pivotal, 其 实 VMWare、Pivotal 和 EMC 本 质 上 是 一 家 。 
不 同 的 是 VMWare 是 独立 上 市 子 公司 ,而 Pivotal 是 整合 了 EMC 的 某 些 资源 , 现在 并 没有 上 市 。 
至 今 你 也 可 以 在 RabbitMQ 的 官网 上 的 Logo 旁 看 到 “by Pivotal” 的 字样 ， 如 图 1-2 所 示 。 


ibRabbitMO „pivota 


1-2 $ Logo 


1 RabbitMQ 官网 地 址 是 www.rabbitmq.com. Github 地 址 是 https://github.com/rabbitmq/rabbitmq-server。 
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RabbitMQ 发 展 到 今天 ， 被 越 来 越 多 的 人 认可 ， 这 和 它 在 易 用 性 、 扩 展 性 、 可 靠 性 和 高 可 用 
性 等 方面 的 卓著 表现 是 分 不 开 的 。RabbitMQ 的 具体 特点 可 以 概括 为 以 下 几 点 。 


4* 可 靠 性 : RabbitMQ 使 用 一 些 机 制 来 保证 可 靠 性 ， 如 持久 化 、 传 输 确认 及 发 布 确认 等 。 

信 灵活 的 路 由 : 在 消息 进入 队列 之 前 ， 通 过 交换 器 来 路 由 消息 。 对 于 典型 的 路 由 功能 ， 
RabbitMQ 已 经 提供 了 一 些 内 置 的 交换 器 来 实现 。 针 对 更 复杂 的 路 由 功能 ， 可 以 将 多 个 
交换 器 绑 定 在 一 起 ， 也 可 以 通过 插件 机 制 来 实现 自己 的 交换 器 。 

令 扩展 性 : 多 个 RabbitMQ 节点 可 以 组 成 一 个 集群 ， 也 可 以 根据 实际 业务 情况 动态 地 扩展 
集群 中 节点 。 

* 高 可 用 性 : 队列 可 以 在 集群 中 的 机 器 上 设置 镜像 , 使 得 在 部 分 节点 出 现 问题 的 情况 下 队 
列 仍然 可 用 。 

仿 多 种 协议 : RabbitMQ 除了 原生 支持 AMQP 协议 ， 还 支持 STOMP. MQTT 等 多 种 消息 
中 间 件 协议 。 

€ 多 语言 客户 端 : RabbitMQ 几乎 支持 所 有 常用 语言 ， 比 如 Java. Python, Ruby. PHP, 
CA. JavaScript 等 。 

仿 管理 界面 : RabbitMQ 提供 了 一 个 易 用 的 用 户 界面 ， 使 得 用 户 可 以 监控 和 管理 消息 、 集 
群 中 的 节点 等 。 

信 插件 机 制 : RabbitMQ 提供 了 许多 插件 ， 以 实现 从 多 方面 进行 扩展 ， 当 然 也 可 以 编写 自 
己 的 插件 。 


14 RabbitMQ 的 安装 及 简单 使 用 





这 里 首先 介绍 RabbitMQ 的 安装 过 程 ， 然 后 演示 发 送 和 消费 消息 的 具体 实现 ， 以 期 让 读者 
对 RabbitMQ 有 比较 直观 的 感受 。 


前 面 提 到 了 RabbitMQ 是 由 Erlang 语言 编写 的 ， 也 正 因 如 此 ， 在 安装 RabbitMQ 之 前 需要 
安装 Erlang。 建 议 采 用 较 新 版 的 Erlang， 这 样 可 以 获得 较 多 更 新 和 改进 ， 可 以 到 官网 
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Chttp://www.erlang.org/downloads) 下 载 。 截 止 本 书 撰 稿 ， 最 新 版 本 为 20.0， 本 书 示例 大 多 采用 
19.x 的 版 本 。 


本 书 如 无 特 指 , 所 有 程序 都 是 在 Linux 下 运行 的 , 毕竟 RabbitMQ 大 多 部 署 在 Linux 操作 系 
统 之 中 。 


1.4.1 安装 Erlang 


下 面 首先 演示 Erlang 的 安装 。 第 一 步 ， 解 压 安 装 包 ， 并 配置 安装 目录 ， 这 里 我 们 预备 安装 
到 /opt/erlang 目录 下 : 


[root@hidden ~]# tar zxvf otp src 19.3.tar.gz 
[root@hidden ~]# cd otp src 19.3 
[root@hidden otp src 19.3]# ./configure --prefix=/opt/erlang 


第 二 步 ， 如 果 出 现 类 似 关 键 报错 信息 : No curses library functions found。 那 么 此 时 需要 安装 
ncurses， 安 装 步骤 〈 遇 到 提示 输入 y 后 直接 回 车 即 可 ) 如 下 : 

[root@hidden otp src 19.3]# yum install ncurses-devel 

第 三 步 ， 安 装 Erlang: 


[root@hidden otp src 19.3]# make 
[root@hidden otp src 19.3]# make install 


如 果 在 安装 的 过 程 中 出 现 类 似 “No ***** found” 的 提示 ， 可 根据 提示 信息 安装 相应 的 包 ， 
之 后 再 执行 第 二 或 者 第 三 步 ， 直 到 提示 安装 完毕 为 止 。 


第 四 步 ， 修 改 /etc/profile 配置 文件 ， 添 加 下 面 的 环境 变量 : 


ERLANG HOME=/opt/erlang 
export PATH=$PATH:$ERLANG HOME/bin 
export ERLANG HOME 


最 后 执行 如 下 命令 让 配置 文件 生效 : 


[root@hidden otp src 19.3]4 source /etc/profile 


可 以 输入 erl 命令 来 验证 Erlang 是 否 安装 成 功 , 如 果 出 现 类 似 以 下 的 提示 即 表 示 安 装 成 功 : 


[rootühidden ~]# erl 
Erlang/OTP 19 [erts-8.1] [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] 
[kernel-poll:false] 
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Eshell V8.1 (abort with ^G) 
1» 


1.4.2. RabbitMQ 的 安装 


RabbitMQ 的 安装 比 Erlang 的 安装 要 简单 , 直接 将 下 载 的 安装 包 解压 到 相应 的 目录 下 即 可 ， 
官网 下 载 地 址 : http:/www.rabbitmq.com/releases/rabbitmq-server/。 本 书 撰 稿 时 的 最 新 版 本 为 
3.6.12， 本 书 示例 大 多 采用 同一 系列 的 3.6.x 版 本 。 


这 里 选择 将 RabbitMQ 安装 到 与 Erlang 同一 个 目录 (/opt) 下 面 : 

[root@hidden ~]# tar zvxf rabbitmq-server-generic-unix-3.6.10.tar.gz -C /opt 
[rootQhidden ~]# cd /opt 

[root(hidden ~]# mv rabbitmq server-3.6.10 rabbitmq 


同样 修改 /etc/profile 文件 ， 添 加 下 面 的 环境 变量 : 


export PATH=$PATH:/opt/rabbitmq/sbin 
export RABBITMQ HOME-/opt/rabbitmq 


之 后 执行 source/etc/profile 命令 让 配置 文件 生效 。 


1.4.8 RabbitMQ 的 运行 


在 修改 了 /etc/profile 配置 文件 之 后 ， 可 以 任意 打开 一 个 Shell 窗口 ， 输 入 如 下 命令 以 
运行 RabbitMQ 服务 : 


rabbitmq-server -detached 


在 rabbitmq-server 命令 后 面 添加 一 个 “-detached” 参 数 是 为 了 能 够 让 RabbitMQ 
服务 以 守护 进程 的 方式 在 后 台 运行 ， 这 样 就 不 会 因为 当前 Shell 窗口 的 关闭 而 影响 服务 。 


运行 rabbitmqctl status 命令 查看 RabbitMQ 是 否 正 常 启动 ， 示 例如 下 : 


[root@hidden ~]# rabbitmqctl status 
Status of node rabbit@hidden 
[{pid, 6458}, 
{running_applications, 
[{rabbitmq_management, "RabbitMQ Management Console", "3.6.10"}, 
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(rabbitmq management agent,"RabbitMO Management Agent","3.6.10"), 
(rabbitmq web dispatch,"RabbitMQ Web Dispatcher","3.6.10"), 
(rabbit,"RabbitMQ","3.6.10"), 
(mnesia,"MNESIA CXC 138 12","4.14.1")], 
(amqp client,"RabbitMQ AMQP Client","3.6.10"), 
(os mon,"CPO CXC 138 46","2.4.1"], 
(rabbit common, 
"Modules shared by rabbitmq-server and rabbitmq-erlang-client", 
"3.6.10, 
(compiler,"ERTS CXE 138 10","7.0.2"), 
(inete, INETS CXC 138 49","6.3,3"], 
(cowboy,"Small, fast, modular HTTP server.","1.0.4"), 
(ranch,"Socket acceptor pool for TCP protocols.","1.3.0"], 
(ssl,"Erlang/OTP SSL application","8.0.2"), 
(public key,"Public key infrastructure","1.2"], 
(cowlib,"Support library for manipulating Web protocols.","1.0.2"), 
{crypto "CRYPTO; "3. 7.1"); 
(syntax tools,"Syntax tools","2.1"], 
{asn1, "The Erlang ASN1 compiler version 4.0.4","4.0.4"], 
(xmerl,"XML parser","1.3.12"], 
íSasl,"SASL -CXE 138 11","3.0.1"7, 
(stdlib,"ERTS CXC 138 10","3,.1"), 
[kernel,"ERTS CXC 138 19","5.]1"Y]), 
(os, tunix,linux)), 
(erlang version, 
"Erlang/OTP 19 [erts-8.1] [source] [64-bit] [smp:4:4] 
[async-threads:64] [hipe] [kernel-poll:true]Mn"], 
(memory, 
[{total, 61061688}, 
{connection_readers, 0}, 
{connection_writers,0}, 
{connection_channels, 0}, 
{connection_other, 2832}, 
{queue_procs, 2832}, 
{queue slave procs,0}, 
{plugins, 487104}, 
{other_proc, 21896528}, 
{mnesia, 60800}, 
{metrics, 193616}, 
{mgmt_db, 137720}, 
{msg_index, 43392}, 
{other_ets,2485240}, 
{binary, 132984}, 
{code, 24661210}, 
{atom, 1033401}, 
{other system,10114813}]}, 
(alarms,[]), 
(listeners, [(clustering,25672,"::"],(amqp,5672,":2"],[http,15672,": e ") T F; 
(vm memory high watermark,0.4], 
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(vm memory limit,3301929779)], 
(disk free limit,50000000), 
(disk free,30244855808], 
(file descriptors, 
[(total limit,924),(total used,2]),(sockets limit,829],(sockets used,0]]), 
(processes, [{limit, 1048576}, (used,323]]], 
(run queue, 0], 
(uptime,11), 
{kernel, {net ticktime,60]]] 


如 果 RabbitMQ 正常 启动 ， 会 输出 如 上 所 示 的 信息 。 当 然 也 可 以 通过 rabbitmqctl 
cluster status 命令 来 查看 集群 信息 ， 目 前 只 有 一 个 RabbitMQ 服务 节点 ， 可 以 看 作 单 节点 
的 集群 : 


[root(hidden ~]# rabbitmqctl cluster status 
Cluster status of node rabbitühidden 
[ (nodes, [(disc, [rabbitGhidden]])]]), 
(running nodes, [rabbitGhidden]], 
(cluster name,««"rabbitGhidden"»»], 
ipartitions,I), 
(alarms,[(rabbitGhidden, [])1)] 


在 后 面 的 7.1 节 中 会 对 多 节点 的 集群 配置 进行 介绍 。 


1.4.4 生产 和 消费 消息 


本 节 将 演示 如 何 使 用 RabbitMQ Java 客户 端 生产 和 消费 消息 。 本 书 中 如 无 特殊 说 明 ， 示 例 
都 采用 Java 语言 来 演示 ， 包 括 RabbitMQ 官方 文档 基本 上 也 是 采用 Java 语言 来 进行 演示 的 。 当 
然 如 前 面 所 提 及 的 ，RabbitMQ 客户 端 可 以 支持 很 多 种 语言 。 


目前 最 新 的 RabbitMQ Java 客户 端 版 本 为 4.2.1， 相 应 的 maven 构建 文件 如 下 : 


«!-- https://mvnrepository.com/artifact/com.rabbitmq/amqp-client --» 
«dependency» 
«groupId»com.rabbitmq«/groupId» 
«artifactId»amqp-client«/artifactId» 
«version»4.2.1«/version» 
«/dependency» 


读者 可 以 根据 项 目的 实际 情况 进行 调节 。 
默认 情况 下 ,访问 RabbitMQ 服务 的 用 户 名 和 密码 都 是 “guest”， 这 个 账户 有 限制 ， 默 认 只 
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能 通过 本 地 网 络 〈 如 localhost) 访问 ， 远 程 网 络 访问 受 限 ， 所 以 在 实现 生产 和 消费 消息 之 前 ， 
需要 另外 添加 一 个 用 户 ， 并 设置 相应 的 访问 权限 。 


添加 新 用 户 ， 用 户 名 为 “root”， 密码 为 “root123”: 


[root@hidden ~]# rabbitmqctl add user root root 
Creating user "root" 


为 root 用 户 设置 所 有 权限 : 

[rootGhidden -]4 rabbitmqctl set permissions =p / root ".*" m au ",x" 
Setting permissions for user "root" in vhost "/" 

设置 root HP EHAR HE: 


[root@hidden ~]# rabbitmqctl set user tags root administrator 
Setting tags for user "root" to [administrator] 


如 果 读 者 在 使 用 RabbitMQ 的 过 程 中 遇 到 类 似 如 下 的 报错 ， 那 么 很 可 能 就 是 账户 管理 的 问 
题 ， 需 要 根据 上 面 的 步骤 进行 设置 ， 之 后 再 运行 程序 。 


Exception in thread "main" com.rabbitmq.client.AuthenticationFailureException: 
ACCESS REFUSED - Login was refused using authentication mechanism PLAIN. For details 
see the broker logfile. 


计算 机 的 世界 是 从 “Hello World!” 开 始 的 ， 这 里 我 们 也 沿用 惯例 ， 首 先生 产 者 发 送 一 条 消 
息 “Hello World!” 至 RabbitMQ 中 ， 之 后 由 消费 者 消费 。 下 面 先 演示 生产 者 客户 端的 代码 〈 代 
码 清单 1-1)， 接 着 再 演示 消费 者 客户 端的 代码 (代码 清单 1-2). 





package com.zzh.rabbitmq.demo; 


import com.rabbitmq.client.Channel; 

import com.rabbitmq.client.Connection; 

import com.rabbitmq.client.ConnectionFactory; 
import com.rabbitmq.client.MessageProperties; 
import java.io.IOException; 

import java.util.concurrent.TimeoutException; 


public class RabbitProducer { 
private static final String EXCHANGE NAME - "exchange demo"; 


private static final String ROUTING KEY - "routingkey demo"; 
private static final String QUEUE NAME - "queue demo"; 
private static final String IP ADDRESS - "192.168.0.2"; 


private static final int PORT = 5672;//RabbitMQ 服务 端 默认 端口 号 为 5672 
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public static void main(String[] args) throws IOException, 
TimeoutException, InterruptedException ( 
ConnectionFactory factory - new ConnectionFactory(); 
factory.setHost(IP ADDRESS); 
factory.setPort (PORT); 
factory.setUsername ("root"); 
factory.setPassword("root123"); 
Connection connection = factory.newConnection();//8]& Eg: 
Channel channel = connection.createChannel();// 创 建 信道 
// 创 建 一 个 type="direct"、 持 久 化 的 、 非 自动 删除 的 交换 器 
channel.exchangeDeclare (EXCHANGE NAME, "direct", true, false, null); 
// 创 建 一 个 持久 化 、 非 排他 的 、 非 自动 删除 的 队列 
channel.queueDeclare (QUEUE NAME, true, false, false, null); 
// 将 交换 器 与 队列 通过 路 由 键 绑 定 
channel.queueBind (QUEUE NAME, EXCHANGE NAME, ROUTING KEY); 
// 发 送 一 条 持久 化 的 消息 : hello world! 
String message = "Hello World!"; 
channel.basicPublish (EXCHANGE NAME, ROUTING KEY, 
MessageProperties.PERSISTENT TEXT PLAIN, 
message.getBytes()); 
// 关 闭 资源 
channel.close(); 
connection.close(); 


) 


为 了 方便 初学 者 能 够 正确 地 运行 本 段 代 码 ， 完 成 “新 手 上 路 ”的 任务 ， 这 里 将 一 个 完整 的 
程序 展示 出 来 。 在 后 面 的 章节 中 ， 如 无 特别 需要 ， 都 只 会 展示 出 部 分 关键 代码 。 


上 面 的 生产 者 客户 端的 代码 首先 和 RabbitMQ 服务 器 建立 一 个 连接 (Connection)， 然 后 在 
这 个 连接 之 上 创建 一 个 信道 CChannel)。 之 后 创建 一 个 交换 器 (Exchange) 和 一 个 队列 (Queue)， 
并 通过 路 由 键 进行 绑 定 〈 在 2.1 节 中 会 有 关于 交换 器 、 队 列 及 路 由 键 的 详细 解释 )。 然 后 发 送 一 
条 消息 ， 最 后 关闭 资源 。 


MES a URN 





package com.zzh.rabbitmqg.demo; 


import com.rabbitmq.client.*; 

import java.io.IOException; 

import java.util.concurrent.TimeUnit; 

import java.util.concurrent.TimeoutException; 


public class RabbitConsumer ( 
private static final String QUEUE NAME - "queue demo"; 
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private static final String IP ADDRESS - "192.168.0.2"; 
private static final int PORT = 5672; 


public static void main(String[] args) throws IOException, 
TimeoutException, InterruptedException { 
Address[] addresses = new Address[](í 
new Address(IP ADDRESS, PORT) 
E 
ConnectionFactory factory - new ConnectionFactory(); 
factory.setUsername ("root"); 
factory.setPassword("rootl123"); 
// 这 里 的 连接 方式 与 生产 者 的 demo 略 有 不 同 ， 注 意 辨别 区 别 
Connection connection = factory.newConnection (addresses); // 创 建 连接 
final Channel channel = connection.createChannel () ;// 创 建 信道 
channel.basicQos (64) ; // 设 置 客户 端 最 多 接收 未 被 ack 的 消息 的 个 数 
Consumer consumer = new DefaultConsumer(channel) { 
GOverride 
public void handleDelivery(String consumerTag, 
Envelope envelope, 
AMOP.BasicProperties properties, 
byte[] body) 
throws IOException ( 
System.out.println("recv message: " + new String (body)); 
try i 
TimeUnit.SECONDS.sleep(1); 
) catch (InterruptedException e) { 
e.printStackTrace(); 


) 
channel.basicAck(envelope.getDeliveryTag(), false); 


}; 
channel .basicConsume (QUEUE NAME, consumer); 


/ /等待 回调 函数 执行 完毕 之 后 ， 关 闭 资源 
TimeUnit.SECONDS.sleep(5); 
channel.close(); 
connection.close(); 


) 


注意 这 里 采用 的 是 继承 De£aultConsumer 的 方式 来 实现 消费 ， 有 过 RabbitMQ 使 用 经 验 
的 读者 也 许 会 喜欢 采用 QueueingConsumer 的 方式 来 实现 消费 ， 但 是 我 们 并 不 推荐 ， 使 用 
QueueingConsumer 会 有 一 些 隐患 。 同 时 ， 在 RabbitMQ Java 客户 端 4.0.0 版 本 开始 将 
QueueingConsumer 标记 为 《GDeprecated, 在 后 面 的 大 版 本 中 会 删除 这 个 类 ， 更 多 详细 内 容 
可 以 参考 4.9.3 节 。 
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通过 上 面 的 演示 ， 相 信 各 位 读者 对 RabbitMQ 有 了 一 个 初步 的 认识 。 但 是 这 也 仅仅 是 个 开 
始 ， 路 漫漫 其 修 远 今 ， 愿 君 能 上 下 而 求索 。 
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本 章 首先 针对 消息 中 间 件 做 了 一 个 摘要 性 的 介绍 ， 包 括 什 么 是 消息 中 间 件 、 消 息 中 间 件 
的 作用 及 消息 中 间 件 的 特点 等 。 之 后 引入 RabbitMQ， 对 其 历史 做 一 个 简单 的 阐述 ， 比 如 
RabbitMQ 具备 哪些 特点 。 本 章 后 面 的 篇 幅 介 绍 了 RabbitMQ 的 安装 及 简单 使 用 ， 通 过 演示 生 
产 者 生产 消息 , 以 及 消费 者 消费 消息 来 给 读者 一 个 对 于 RabbitMQ 的 最 初 的 印象 , 为 后 面 的 探 
索 过 程 打下 基础 。 
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第 1 章 的 内 容 让 我 们 对 消息 中 间 件 和 RabbitMQ 本 身 有 了 大 致 的 印象 ， 但 这 是 最 浅显 的 。 
A TERRI RabbitMQ 的 大 门 ， 还 需要 针对 RabbitMQ 本 身 及 其 所 遵循 的 AMQP 协议 中 的 一 
些 细节 做 进一步 的 探究 。 在 阅读 本 章 内 容 的 时 候 可 以 带 着 这 样 的 一 些 疑 问 : RabbitMQ 的 模型 架 
构 是 什么 ? AMQP 协议 又 是 什么 ? 这 两 者 之 间 又 有 何 种 紧密 的 关系 ? 消息 从 生产 者 发 出 到 消费 
者 消费 这 一 过 程 中 要 经 历 一 些 什 么 ? 
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2 . 1 相关 概 ; Sia 





RabbitMQ 整体 上 是 一 个 生产 者 与 消费 者 模型 ， 主 要 负责 接收 、 存 储 和 转发 消息 。 可 以 把 消 
息 传递 的 过 程 想 象 成 :， 当 你 将 一 个 包裹 送 到 邮局 ， 邮 局 会 暂 存 并 最 终 将 邮件 通过 邮递 员 送 到 收 
件 人 的 手 上 , RabbitMQ 就 好 比 由 邮局 、 邮 箱 和 邮递 员 组 成 的 一 个 系统 ,从 计算 机 术语 层面 来 说 ， 
RabbitMQ 模型 更 像 是 一 种 交换 机 模型 。 


RabbitMQ 的 整体 模型 架构 如 图 2-1 所 示 。 


——————————Á—— — À— ——— a S a 
- LN 


+ 





图 2-1 RabbitMQ 的 模型 架构 


2.1.1 生产 者 和 消费 者 


Producer: 生产 者 ， 就 是 投递 消息 的 一 方 。 


生产 者 创建 消息 ， 然 后 发 布 到 RabbitMQ 中 。 消 息 一 般 可 以 包含 2 个 部 分 : 消息 体 和 标签 
(Label)。 消 息 体 也 可 以 称 之 为 payload， 在 实际 应 用 中 ， 消 息 体 一 般 是 一 个 带 有 业务 逻辑 结构 
的 数据 ， 比 如 一 个 JSON 字符 串 。 当 然 可 以 进一步 对 这 个 消息 体 进行 序列 化 操作 。 消 息 的 标签 
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用 来 表述 这 条 消息 ， 比 如 一 个 交换 器 的 名 称 和 一 个 路 由 键 。 生 产 者 把 消息 交 由 RabbitMQ， 
RabbitMQ 之 后 会 根据 标签 把 消息 发 送 给 感 兴趣 的 消费 者 (Consumer)。 


Consumer: 消费 者 ， 就 是 接收 消息 的 一 方 。 

消费 者 连接 到 RabbitMQ 服务 器 ， 并 订阅 到 队列 上 。 当 消费 者 消费 一 条 消息 时 ， 只 是 消费 
消息 的 消息 体 (payload)。 在 消息 路 由 的 过 程 中 ， 消 息 的 标签 会 丢弃 ， 存 入 到 队列 中 的 消息 只 
有 消息 体 ， 消 费 者 也 只 会 消费 到 消息 体 ， 也 就 不 知道 消息 的 生产 者 是 谁 ， 当 然 消费 者 也 不 需要 
知道 。 

Broker: 消息 中 间 件 的 服务 节点 。 

对 于 RabbitMQ 来 说 ， 一 个 RabbitMQ Broker 可 以 简单 地 看 作 一 个 RabbitMQ 服务 节点 ， 


或 者 RabbitMQ 服务 实例 。 大 多 数 情况 下 也 可 以 将 一 个 RabbitMQ Broker 看 作 一 台 RabbitMQ 
服务 器 。 


2-2 展示 了 生产 者 将 消息 存 入 RabbitMQ Broker， 以 及 消费 者 从 Broker 中 消费 数据 的 整 
个 流程 。 





Producer 指定 Excharee 和 Routingkey 竺 
en Excha outi , 

| rms |] Ptr | MOAS 

' 业务 方 数据 ' -daa a 


2-2 ”消息 队列 的 运转 过 程 


首先 生产 者 将 业务 方 数据 进 行 可 能 的 包装 ， 之 后 封装 成 消息 ， 发 送 (AMQP 协议 里 这 个 动 
作对 应 的 命令 为 Basic.Publish) 到 Broker 中 。 消 费 者 订阅 并 接收 消息 AMQP 协议 里 这 个 
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动作 对 应 的 命令 为 Basic.Consume 或 者 Basic.Get), 经 过 可 能 的 解 包 处 理 得 到 原始 的 数据 ， 
之 后 再 进行 业务 处 理 逻 辑 。 这 个 业务 处 理 逻 辑 并 不 一 定 需 要 和 接收 消息 的 逻辑 使 用 同一 个 线程 。 
消费 者 进程 可 以 使 用 一 个 线程 去 接收 消息 , 存 入 到 内 存 中 ,比如 使 用 Java 中 的 BlockingQueue。 
业务 处 理 逻 辑 使 用 另 一 个 线程 从 内 存 中 读 取 数 据 ， 这 样 可 以 将 应 用 进一步 解 厢 ， 提 高 整个 应 用 
的 处 理 效 率 。 


2.1.2 ”队列 


Queue: 队列 ， 是 RabbitMQ 的 内 部 对 象 ， 用 于 存储 消息 。 参 考 图 2-1， 队 列 可 以 用 图 2-3 
表示 。 


Queue 


TET] 


2-3 ”队列 
RabbitMQ 中 消息 都 只 能 存储 在 队列 中 ， 这 一 点 和 Kafka 这 种 消息 中 间 件 相反 。Kafka 将 消 
息 存 储 在 topic ($) 这 个 逻辑 层面 ， 而 相对 应 的 队列 逻辑 只 是 topic 实际 存储 文件 中 的 位 移 
标识 。 RabbitMQ 的 生产 者 生产 消息 并 最 终 投递 到 队列 中 , 消费 者 可 以 从 队列 中 获取 消息 并 消费 。 
多 个 消费 者 可 以 订阅 同一 个 队列 , 这 时 队列 中 的 消息 会 被 平均 分 挫 (Round-Robin, 即 轮 询 ) 
给 多 个 消费 者 进行 处 理 ， 而 不 是 每 个 消费 者 都 收 到 所 有 的 消息 并 处 理 ， 如 图 2-4 所 示 。 





图 2-4 多 个 消费 者 
RabbitMQ 不 支持 队列 层面 的 广播 消费 ,如 果 需 要 广播 消费 ， 需 要 在 其 上 进行 二 次 开发 ， 处 
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理 逻 辑 会 变 得 异常 复杂 ， 同 时 也 不 建议 这 么 做 。 


Exchange: 交换 器 。 在 图 2-4 中 我 们 暂时 可 以 理解 成 生产 者 将 消息 投递 到 队列 中 ， 实 际 上 
这 个 在 RabbitMQ 中 不 会 发 生 。 真 实情 况 是 ， 生 产 者 将 消息 发 送 到 Exchange (交换 器 ， 通 常 也 
可 以 用 大 写 的 “X” 来 表示 )， 由 交换 器 将 消息 路 由 到 一 个 或 者 多 个 队列 中 。 如 果 路 由 不 到 ， 或 
许 会 返回 给 生产 者 ， 或 许 直接 丢弃 。 这 里 可 以 将 RabbitMQ 中 的 交换 器 看 作 一 个 简单 的 实体 ， 
更 多 的 细节 会 在 后 面 的 章节 中 有 所 涉及 。 


交换 器 的 具体 示意 图 如 图 2-5 所 示 。 





图 2-5 交换 器 


RabbitMQ 中 的 交换 器 有 四 种 类 型 ,不同 的 类 型 有 着 不 同 的 路 由 策略 , 这 将 在 下 一 节 的 交换 
器 类 型 (Exchange Types) 中 介绍 。 


RoutingKey: 路 由 键 。 生 产 者 将 消息 发 给 交换 器 的 时 候 ， 一 般 会 指定 一 个 RoutingKey， 用 
来 指定 这 个 消息 的 路 由 规则 ， 而 这 个 Routing Key 需要 与 交换 器 类 型 和 绑 定 键 (BindingKey) HX 
合 使 用 才能 最 终生 效 。 


在 交换 器 类 型 和 绑 定 键 (BindingKey) 固定 的 情况 下 , 生产 者 可 以 在 发 送 消息 给 交换 器 时 ， 
通过 指定 RoutingKey 来 决定 消息 流向 哪里 。 


Binding: 绑 定 。RabbitMQ 中 通过 绑 定 将 交换 器 与 队列 关联 起 来 ， 在 绑 定 的 时 候 一 般 会 指 
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定 一 个 绑 定 键 (BindingKey), 这 样 RabbitMQ 就 知道 如 何 正确 地 将 消息 路 由 到 队列 了 ,如 图 2-6 
所 示 。 





生产 者 将 消息 发 送 给 交换 器 时 ， 需 要 一 个 RoutingKey， 当 BindingKey 和 RoutingKey 相 匹 
配 时 ， 消 息 会 被 路 由 到 对 应 的 队列 中 。 在 绑 定 多 个 队列 到 同一 个 交换 器 的 时 候 ， 这 些 绑 定 允许 
使 用 相同 的 BindingKey。BindingKey 并 不 是 在 所 有 的 情况 下 都 生效 ， 它 依赖 于 交换 器 类 型 ， 比 
如 fanout 类 型 的 交换 器 就 会 无 视 BindingKey, 而 是 将 消息 路 由 到 所 有 绑 定 到 该 交换 器 的 队列 中 。 


对 于 初学 者 来 说 ， 交 换 器 、 路 由 键 、 绑 定 这 几 个 概念 理解 起 来 会 有 点 睡 涩 ， 可 以 对 照 着 代 
码 清单 1-1 来 加 深 理 解 。 


沿用 本 章 开 头 的 比喻 ， 交 换 器 相当 于 投递 包 里 的 邮箱 ，RoutingKey 相当 于 填写 在 包 训 上 的 
地 址 ，BindingKey 相当 于 包 庄 的 目的 地 ， 当 填写 在 包裹 上 的 地 址 和 实际 想 要 投递 的 地 址 相 匹配 
时 ， 那 么 这 个 包 于 就 会 被 正确 投递 到 目的 地 ， 最 后 这 个 目的 地 的 “主人 ”一 一 队列 可 以 保留 这 
个 包 庄 。 如 果 填 写 的 地 址 出 错 ， 邮 有 递 员 不 能 正确 投递 到 目的 地 ， 包 训 可 能 会 回 退 给 寄 件 人 ， 也 
有 可 能 被 丢弃 。 


有 经 验 的 读者 可 能 会 发 现 , 在 某 些 情形 下 , RoutingKey 与 BindingKey 可 以 看 作 同 一 个 东西 。 





channel.exchangeDeclare (EXCHANGE NAME, "direct", true, false, null); 
channel.queueDeclare (QUEUE NAME, true, false, false, null); 
channel.queueBind (QUEUE NAME, EXCHANGE NAME, ROUTING KEY); 
String message - "Hello World!"; 
channel.basicPublish (EXCHANGE NAME, ROUTING KEY, 
MessageProperties.PERSISTENT TEXT PLAIN, 
message.getBytes()); 
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以 上 代码 声明 了 一 个 direct 类 型 的 交换 器 (交换 器 的 类 型 在 下 一 节 会 详细 讲述 )， 然 后 将 交 
换 器 和 队列 绑 定 起 来 。 注 意 这 里 使 用 的 字样 是 “ROUTING _ KEY”， 在 本 该 使 用 BindingKey 的 
channel.queueBind 方法 中 却 和 channel.basicPublish 方法 同样 使 用 了 RoutingKey， 
这 样 做 的 潜台词 是 : 这 里 的 RoutingKey 和 BindingKey 是 同一 个 东西 。 在 direct 交换 器 类 型 下 ， 
RoutingKey 和 BindingKey 需要 完全 匹配 才能 使 用 , 所 以 上 面 代码 中 采用 了 此 种 写法 会 显得 方便 
许多 。 
但 是 在 topic 交换 器 类 型 下 ，RoutingKey 和 BindingKey 之 间 需 要 做 模糊 匹配 ， 两 者 并 不 是 
相同 的 。 
BindingKey 其 实 也 属于 路 由 键 中 的 一 种 , 官方 解释 为 : the routing key to use for the binding, 
可 以 翻译 为 :在 绑 定 的 时 候 使 用 的 路 由 键 。 大 多 数 时 候 ， 包 插 官 方 文档 和 RabbitMQ Java API 
中 都 把 BindingKey 和 RoutingKey 看 作 RoutingKey， 为 了 避免 混淆 ， 可 以 这 么 理解 : 
€ 在 使 用 绑 定 的 时 候 ， 其 中 需要 的 路 由 键 是 BindingKey。 涉 及 的 客户 端 方法 如 : 
channel .exchangeBind、channel.dqueueBind， 对 应 的 AMQP 命令 (详情 参见 
228) Jj Exchange.Bind. Queue.Bind. 


€ 在 发 送 消息 的 时 候 ， 其 中 需要 的 路 由 键 是 RoutingKey 。 涉 及 的 客户 端 方法 如 
channel.basicPublish， 对 应 的 AMQP 命令 为 Basic.Publish。 


由 于 某 些 历史 的 原因 ,包括 现存 能 搜集 到 的 资料 显示 :大 多 数 情况 下 习惯 性 地 将 BindingKey 
写成 RoutingKey， 尤 其 是 在 使 用 direct 类 型 的 交换 器 的 时 候 。 本 文 后 面 的 篇 幅 中 也 会 将 两 者 合 
称 为 路 由 键 ， 读 者 需要 注意 区 分 其 中 的 不 同 ， 可 以 根据 上 面 的 辨别 方法 进行 有 效 的 区 分 。 


2.1.4 ”交换 器 类 型 


RabbitMQ 常用 的 交换 器 类 型 有 fanout、direct、topic、headers 这 四 种 。AMQP 协议 里 还 提 
到 另外 两 种 类 型 : System 和 自 定义 ， 这 里 不 予 描述 。 对 于 这 四 种 类 型 下 面 一 一 阐述 。 
fanout 


它 会 把 所 有 发 送 到 该 交换 器 的 消息 路 由 到 所 有 与 该 交换 器 绑 定 的 队列 中 。 
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direct 


direct 类 型 的 交换 器 路 由 规则 也 很 简单 ， 它 会 把 消息 路 由 到 那些 BindingKey 和 RoutingKey 
完全 匹配 的 队列 中 。 


以 图 2-7 为 例 ， 交 换 器 的 类 型 为 direct， 如 果 我 们 发 送 一 条 消息 ， 并 在 发 送 消息 的 时 候 设置 
路 由 键 为 “warning”， 则 消息 会 路 由 到 Queuel 和 Queue2, 对 应 的 示例 代码 如 下 : 


channel.basicPublish (EXCHANGE NAME, "warning", 
MessageProperties. PERSISTENT TEXT PLAIN, 
message.getBytes()); 





图 2-7 direct 类 型 的 交换 器 


如 果 在 发 送 消息 的 时 候 设 置 路 由 键 为 “info” 或 者 “debug”， 消 息 只 会 路 由 到 Queue2。 如 
果 以 其 他 的 路 由 键 发 送 消 息 ， 则 消息 不 会 路 由 到 这 两 个 队列 中 。 


topic 


前 面 讲 到 direct 类 型 的 交换 器 路 由 规则 是 完全 匹配 BindingKey 和 RoutingKey, 但 是 这 种 严 
格 的 匹配 方式 在 很 多 情况 下 不 能 满足 实际 业务 的 需求 。topic 类 型 的 交换 器 在 匹配 规则 上 进行 了 
扩展 , 它 与 direct 类 型 的 交换 器 相似 , 也 是 将 消息 路 由 到 BindingKey 和 RoutingKey 相 匹 配 的 队 
列 中 ， 但 这 里 的 匹配 规则 有 些 不 同 ， 它 约定 : 


* RoutingKey 为 一 个 点 号 “. ”分 隔 的 字符 串 〈 被 点 号 “. ”分 隔 开 的 每 一 段 独立 的 字符 


串 称 为 一 个 单词 ), 如 “com.rabbitmq.client”、“java.util.concurrent”、“com.hidden.client”; 
仿 BindingKey 和 RoutingKey 一 样 也 是 点 号 “. ”分 隔 的 字符 串 ; 
信 BindingKey 中 可 以 存在 两 种 特殊 字符 串 “*” 和 “#” 用 于 做 模糊 匹配 ， 其 中 “#” 用 
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于 匹配 一 个 单词 ,，“#” 用 于 匹配 多 规格 单词 (可 以 是 零 个 )。 
以 图 2-8 中 的 配置 为 例 : 
e 路 由 键 为 “com.rabbitmq.client” 的 消息 会 同时 路 由 到 Queuel 和 Queue2; 
€ 路 由 键 为 “com.hidden.client” 的 消息 只 会 路 由 到 Queue2 中 ; 
€ 路 由 键 为 “com.hidden.demo” 的 消息 只 会 路 由 到 Queue2 中 ; 
© 路 由 键 为 “java.rabbitmq.demo” 的 消息 只 会 路 由 到 Queuel rf; 


© 路 由 键 为 “java.util.concurrent” 的 消息 将 会 被 丢弃 或 者 返回 给 生产 者 (需要 设置 
mandatory 参数 )， 因 为 它 没有 匹配 任何 路 由 键 。 





图 2-8 topic 类 型 的 交换 器 


headers 


headers 类 型 的 交换 器 不 依赖 于 路 由 键 的 匹配 规则 来 路 由 消息 , 而 是 根据 发 送 的 消息 内 容 中 
的 headers 属性 进行 匹配 。 在 绑 定 队列 和 交换 器 时 制定 一 组 键 值 对 , 当 发 送 消息 到 交换 器 时 ， 
RabbitMQ 会 获取 到 该 消息 的 headers (也 是 一 个 键 值 对 的 形式 ), 对比 其 中 的 键 值 对 是 否 完全 
匹配 队列 和 交换 器 绑 定时 指定 的 键 值 对 ， 如 果 完 全 匹配 则 消息 会 路 由 到 该 队列 ， 否 则 不 会 路 由 
到 该 队列 。headers 类 型 的 交换 器 性 能 会 很 差 ， 而 且 也 不 实用 ， 基 本 上 不 会 看 到 它 的 存在 。 


2.1.5 RabbitMQ 运转 流程 


了 解 了 以 上 的 RabbitMQ 架构 模型 及 相关 术语 ， 再 来 回顾 整个 消息 队列 的 使 用 过 程 。 在 最 
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初 状态 下 ， 生 产 者 发 送 消 息 的 时 候 《〈 可 依照 图 2-1): 


CD 生产 者 连接 到 RabbitMQ Broker, 建立 一 个 连接 (Connection), 开启 一 个 信道 (Channel) 
(详细 内 容 请 参考 3.1 节 )。 


(2) 生产 者 声明 一 个 交换 器 ， 并 设置 相关 属性 ， 比 如 交换 机 类 型 、 是 否 持久 化 等 (详细 内 
容 请 参考 3.2 节 )。 


(3) 生产 者 声明 一 个 队列 并 设置 相关 属性 ， 比 如 是 否 排他 、 是 否 持久 化 、 是 否 自动 删除 等 
(详细 内 容 请 参考 3.2 节 )。 


(4) 生产 者 通过 路 由 键 将 交换 器 和 队列 绑 定 起 来 (详细 内 容 请 参考 3.2 TD. 


(5) 生产 者 发 送 消 息 至 RabbitMQ Broker， 其 中 包含 路 由 键 、 交 换 器 等 信息 (详细 内 容 请 参 
考 3.3 节 )。 


(6) 相应 的 交换 器 根据 接收 到 的 路 由 键 查找 相 匹配 的 队列 。 
C) 如 果 找 到 ， 则 将 从 生产 者 发 送 过 来 的 消息 存 入 相应 的 队列 中 。 


(8) 如 果 没 有 找到 ， 则 根据 生产 者 配置 的 属性 选择 丢弃 还 是 回 退 给 生产 者 (详细 内 容 请 参 
考 4.1 节 )。 


(9) 关闭 信道 。 

(10) 关闭 连接 。 

消费 者 接收 消息 的 过 程 : 

(1) 消 费 者 连接 到 RabbitMQ Broker, 建立 一 个 连接 (Connection), 开启 一 个 信道 (Channel)。 


(25 消费 者 向 RabbitMQ Broker 请 求 消费 相应 队列 中 的 消息 , 可 能 会 设置 相应 的 回调 函数 ， 
以 及 做 一 些 准 备 工作 (详细 内 容 请 参考 3.4 节 )。 


(3) 等 待 RabbitMQ Broker 回应 并 投递 相应 队列 中 的 消息 ， 消 费 者 接收 消息 。 
(4) 消费 者 确认 (ack) 接收 到 的 消息 。 

(5) RabbitMQ 从 队列 中 删除 相应 已 经 被 确认 的 消息 。 

(6) 关闭 信道 。 
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(7) 关闭 连接 。 


如 图 2-9 所 示 ， 我 们 又 引入 了 两 个 新 的 概念 : Connection 和 Channel。 我 们 知道 无 论 是 生产 
者 还 是 消费 者 ， 都 需要 和 RabbitMQ Broker 建立 连接 ， 这 个 连接 就 是 一 条 TCP 连接 ， 也 就 是 
Connection。 一 旦 TCP 连接 建立 起 来 ， 客 户 端 紧 接着 可 以 创建 一 个 AMQP 信道 (ChanneD, 4$ 
个 信道 都 会 被 指派 一 个 唯一 的 ID。 信道 是 建立 在 Connection 之 上 的 虚拟 连接 ，RabbitMQ 处 理 
的 每 条 AMQP 指令 都 是 通过 信道 完成 的 。 


通道 复 用 TCP 连 接 RabbitMQ Broker 





2-9 Connection 与 Channel 


我 们 完全 可 以 直接 使 用 Connection 就 能 完成 信道 的 工作 ， 为 什么 还 要 引入 信道 呢 ? 试想 这 
样 一 个 场景 ， 一 个 应 用 程序 中 有 很 多 个 线程 需要 从 RabbitMQ 中 消费 消息 ， 或 者 生产 消息 ， 那 
么 必然 需要 建立 很 多 个 Connection， 也 就 是 许多 个 TCP 连接 。 然 而 对 于 操作 系统 而 言 ， 建 立 和 
销毁 TCP 连接 是 非常 昂贵 的 开销 ， 如 果 遇 到 使 用 高 峰 ， 性 能 瓶颈 也 随 之 显现 。RabbitMQ 采用 
类 似 NIO! (Non-blocking IO) 的 做 法 ， 选 择 TCP 连接 复 用 ， 不 仅 可 以 减少 性 能 开销 ， 同 时 也 
便于 管理 。 


! NIO， 也 称 非 阻塞 /JO， 包 含 三 大 核心 部 分 :Channel UŠ), Buffer (ZPPX) 和 Selector (选择 器 )。NIO 基于 Channel 和 
Buffer 进行 操作 ， 数 据 总 是 从 信道 读 取 数据 到 缓冲 区 中 ， 或 者 从 缓冲 区 写 入 到 信道 中 。Selector 用 于 监听 多 个 信道 的 事件 〈 比 
如 连接 打开 ， 数 据 到 达 等 )。 因 此 ， 单 线程 可 以 监听 多 个 数据 的 信道 。NIO 中 有 一 个 很 有 名 的 Reactor 模式 ， 有 兴趣 的 读者 可 以 
深入 研究 。 c 


@25e 


RabbitMQ 实战 指南 


每 个 线程 把 持 一 个 信道 ， 所 以 信道 复 用 了 Connection 的 TCP 连接 。 同 时 RabbitMQ 可 以 确 
保 每 个 线程 的 私密 性 ， 就 像 拥 有 独立 的 连接 一 样 。 当 每 个 信道 的 流量 不 是 很 大 时 ， 复 用 单一 的 
Connection 可 以 在 产生 性 能 瓶颈 的 情况 下 有 效 地 节省 TCP 连接 资源 。 但 是 当 信道 本 身 的 流量 很 
大 时 ， 这 时 候 多 个 信道 复 用 一 个 Connection 就 会 产生 性 能 瓶颈 ， 进 而 使 整体 的 流量 被 限制 了 。 
此 时 就 需要 开辟 多 个 Connection， 将 这 些 信道 均 摊 到 这 些 Connection 中 ， 至 于 这 些 相 关 的 调 优 
策略 需要 根据 业务 自身 的 实际 情况 进行 调节 ， 更 多 内 容 可 以 参考 第 9 章 。 


信道 在 AMQP 中 是 一 个 很 重要 的 概念 ， 大 多 数 操作 都 是 在 信道 这 个 层面 展开 的 。 在 代码 清单 
1-1 中 也 可 以 看 出 一 些 端倪 ， 比 如 channel.exchangeDeclare. channel.queueDeclare, 
channel.basicPublish 和 channel .basicConsume 等 方法 .RabbitMQ 相关 的 API 与 AMQP 
紧密 相连 ， 比 如 channel.basicPublish 对 应 AMQP 的 Basic.Publish 命令 ， 在 下 面 的 小 
节 中 将 会 为 大 家 一 一 展开 。 


2.2 AMQP 协议 介绍 


从 前 面 的 内 容 可 以 了 解 到 RabbitMQ 是 遵从 AMQP 协议 的 , 换 句 话说 ,RabbitMQ 就 是 AMQP 
协议 的 Erlang 的 实现 (当然 RabbitMQ 还 支持 STOMP’, MQTT? HN). AMQP 的 模型 架构 
和 RabbitMQ 的 模型 架构 是 一 样 的 ， 生 产 者 将 消息 发 送 给 交换 器 ， 交 换 器 和 队列 绑 定 。 当 生产 
者 发 送 消息 时 所 携带 的 RoutingKey 与 绑 定时 的 BindingKey 相 匹 配 时 ， 消 息 即 被 存 入 相应 的 队 
列 之 中 。 消 费 者 可 以 订阅 相应 的 队列 来 获取 消息 。 


RabbitMQ 中 的 交换 器 、 交 换 器 类 型 、 队 列 、 绑 定 、 路 由 键 等 都 是 遵循 的 AMQP 协议 中 相 
应 的 概念 。 目 前 RabbitMQ 最 新 版 本 默认 支持 的 是 AMQP 0-9-1。 本 书 中 如 无 特殊 说 明 ， 都 以 
AQMP 0-9-1 为 基准 进行 介绍 。 


? STOMP， 即 Simple (or Streaming) Text Oriented Messaging Protocol， 简 单 〈 流 ) 文本 面向 消息 协议 ， 它 提供 了 一 个 可 互 操作 的 
连接 格式 ， 运 行 STOMP 客户 端 与 任意 STOMP 消息 代理 (Broker) 进行 交互 。STOMP 协议 由 于 设计 简单 ， 易 于 开发 客户 端 ， 
因此 在 多 种 语言 和 平台 上 得 到 广泛 的 应 用 。 

3 MQTT， 即 Message Queuing Telemetry Transport， 消 息 队 列 遥 测 传输 ， 是 IBM 开发 的 一 个 即时 通信 协议 ， 有 可 能 成 为 物 联 网 
的 重要 组 成 部 分 。 该 协议 支持 所 有 平台 ， 几 乎 可 以 把 所 有 物 联 网 和 外 部 连接 起 来 ， 被 用 来 当 作 传感器 和 制动器 的 通信 协议 。 
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AMQP 协议 本 身 包括 三 层 。 
* Module Layer: 位 于 协议 最 高 层 ， 主 要 定义 了 一 些 供 客户 端 调 用 的 命令 ,客户 端 可 以 利 


用 这 些 命 令 实现 自己 的 业务 逻辑 。 例 如 ， 客 户 端 可 以 使 用 Queue.Declare 命令 声明 
一 个 队列 或 者 使 用 Basic.Cconsume 订阅 消费 一 个 队列 中 的 消息 。 


仿 _ Session Layer: 位 于 中 间 层 ， 主 要 负责 将 客户 端的 命令 发 送 给 服务 器 ,再 将 服务 端的 应 
答 返 回 给 客户 端 ， 主 要 为 客户 端 与 服务 器 之 间 的 通信 提供 可 靠 性 同步 机 制 和 错误 处 理 。 
+ Transport Layer: 位 于 最 底层 ， 主 要 传输 二 进 制 数据 流 ， 提 供 帧 的 处 理 、 信 道 复 用 、 错 
AMQP 说 到 底 还 是 一 个 通信 协议 ， 通 信 协 议 都 会 涉及 报 文 交 互 ， 从 low-level 举例 来 说 ， 
AMQP 本 身 是 应 用 层 的 协议 ， 其 填充 于 TCP 协议 层 的 数据 部 分 。 而 从 high-level 来 说 ，AMQP 
是 通过 协议 命令 进行 交互 的 。AMQP 协议 可 以 看 作 一 系列 结构 化 命令 的 集合 ， 这 里 的 命令 代表 
一 种 操作 ， 类 似 于 HTTP 中 的 方法 (GET, POST, PUT, DELETE 等 )。 


2.2.1 AMQP 生产 者 流转 过 程 


为 了 形象 地 说 明 AMQP 协议 命令 的 流转 过 程 ， 这 里 截取 代码 清单 1-1 中 的 关键 代码 ， 如 代 
码 清 单 2-2 所 示 。 





Connection connection = factory.newConnection();// 创 建 连接 

Channel channel = connection.createChannel ();// 创 建 信道 

String message = "Hello World!"; 

channel.basicPublish(EXCHANGE NAME, ROUTING KEY, 
MessageProperties.PERSISTENT TEXT PLAIN, 
message.getBytes()); 

// 关 闭 资源 

channel.close(); 

connection.close(); 


当 客 户 端 与 Broker 建立 连接 的 时 候 , 会 调用 factory.newConnection 方法 ， 这 个 方法 
会 进一步 封装 成 Protocol Header 0-9-1 的 报 文 头 发 送 给 Broker， 以 此 通知 Broker 本 次 交互 采用 
的 是 AMQP 0-9-1 协议 ， 紧 接着 Broker 返回 Connection.Start 来 建立 连接 ， 在 连接 的 过 程 
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中 涉及 Connection.Start/.Start-OK.Connection.Tune/.Tune-Ok. Connection. 
Open/.Open-Ok XX 6 个 命令 的 交互 。 

当 客 户 端 调 用 connection.createChannel 方法 准备 开启 信道 的 时 候 ， 其 包装 
Channel.Open 命令 发 送 给 Broker， 等 待 Channel.Open-Ok 命令 。 


当 客 户 端 发 送 消息 的 时 候 ， 需 要 调用 channel.basicPublish 方法 ， 对 应 的 AQMP 命 
令 为 Basic.Publish, 注意 这 个 命令 和 前 面 涉 及 的 命令 略 有 不 同 ， 这 个 命令 还 包含 了 Content 
Header 和 Content Body. Content Header 里 面包 含 的 是 消息 体 的 属性 ， 例 如 ， 投 递 模式 〈 可 以 参 
考 3.3 节 )、 优 先 级 等 ， 而 Content Body 包含 消息 体 本 身 。 


当 客 户 端 发 送 完 消 息 需 要 关闭 资源 时 ， 涉 及 Channel.Close/.Close-Ok 与 
Connection.Close/.Close-Ok 的 命令 交互 。 详 细 流 转 过 程 如 图 2-10 所 示 。 


————— —À ——————)— "se —————— erro 


Connection.Start-Ok -= atc e 
sich mmt Connection Tune 
d ae 
Connection.Tune-Ok : : 
Connection.Open e 
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temm mmm H 
a i ' 


念 发 送 消息 | Basic. Publish- 本 
GERE T€ ISTE apis 


PE. 
- Channel.Close-Ok : 


' Connection.Close- Tnt MY PH S ERES vi ' 
: Dd A M ->i 
benennen Connection.Close-Ok | 


2-10 ”流转 过 程 
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本 节 我 们 继续 来 看 消费 者 的 流转 过 程 , 参考 代码 清单 1-2, 截取 消费 端的 关键 代码 如 代码 清 
单 2-3 所 示 。 


(5 








Connection connection = factory.newConnection (addresses); //$]£& iE Hc 
final Channel channel = connection.createChanne1l1();// 创 建 信道 
Consumer consumer = new DefaultConsumer(channel) {}//.…. 省 略 实现 
channel.basicQos(64); 


channel.basicConsume (QUEUE NAME, consumer); 
// 等 待 回调 函数 执行 完毕 之 后 ， 关 闭 资源 
TimeUnit.SECONDS.sleep(5); 
channel.close(); 

connection.close(); 


其 详细 流转 过 程 如 图 2-11 所 示 。 
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e 29e 


RabbitMQ 实战 指南 


消费 者 客户 端 同样 需要 与 Broker 建立 连接 ， 与 生产 者 客户 端 一 样 ， 协 议 交 互 同 样 涉及 
Connection.Start/.Start-Ok. Connection.Tune/.Tune-Ok 和 Connection. 


Open/.Open-Ok 等 ， 2-11 中 省 略 了 这 些 步骤 ， 可 以 参考 图 2-10。 


紧 接着 也 少不了 在 Connection 之 上 建立 Channe1， 和 生产 者 客户 端 一 样 ， 协 议 涉 及 
Channel.Open/Open-Ok. 


如 果 在 消费 之 前 调用 了 channel.basicQos (int prefetchCount) 的 方法 来 设置 消费 
者 客户 端 最 大 能 “保持 ”的 未 确认 的 消息 数 ， 那 么 协议 流转 会 涉及 Basic.Qos/.Qos-Ok 这 
两 个 AMQP 命令 。 

在 真正 消费 之 前 ， 消 费 者 客户 端 需要 向 Broker 发 送 Basic.Consume 命令 〈 即 调用 
channel.basicConsume 方法 ) 将 Channel 置 为 接收 模式 ， 之 后 Broker 回执 
Basic.Consume-Ok 以 告诉 消费 者 客户 端 准 备 好 消费 消息 。 紧 接着 Broker 向 消费 者 客户 端 推 
送 (Push) 消息 ， 即 Basic.Deliver 命令 ， 有 意思 的 是 这 个 和 Basic.Publish 命令 一 样 会 
携带 Content Header 和 Content Body。 


消费 者 接收 到 消息 并 正确 消费 之 后 ， 向 Broker 发 送 确认 ， 即 Basic.Ack 命令 。 


在 消费 者 停止 消费 的 时 候 ， 主 动 关 闭 连 接 ， 这 点 和 生产 者 一 样 ， 涉 及 
Channel.Close/.Close-OkÍll Connection.Close/.Close-Ok. 


2.2.3 AMQP 命令 概览 


AMQP 0-9-1 协议 中 的 命令 远 远 不 止 上 面 所 涉及 的 这 些 , 为 了 让 读者 在 遇 到 其 他 命令 的 时 候 
能 够 迅速 查阅 相关 信息 ， 下 面 列举 了 AMQP 0-9-1 协议 主要 的 命令 ， 包 含 名 称 、 是 否 包含 内 容 
体 (Content Body)、 对 应 客户 端 中 相应 的 方法 及 简要 描述 等 四 个 维度 进行 说 明 ， 具 体 如 表 2-1 
所 示 。 


表 2-1 AMQP 命令 


是 否 包 含 内 容 体 对 应 客户 端 中 的 方法 简要 描述 
建立 连接 相关 
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小 结 


本 章 主要 讲述 的 是 RabbitMQ 的 入 门 知识 ， 首 先 介 绍 了 生产 者 〈Producer )、 消 费 者 
(CConsumer)、 队 列 〈Queue)、 交 换 器 (Exchange)、 路 由 键 (RoutingKey)、 绑 定 (Binding), 
连接 (Connection) 和 信道 《Channel) 等 基本 术语 , 还 介绍 了 交换 器 的 类 型 : fanout、 direct、 topic 
和 headers。 之 后 通过 介绍 RabbitMQ 的 运转 流程 来 加 深 对 基本 术语 的 理解 。 


RabbitMQ 可 以 看 作 AMQP 协议 的 具体 实现 ，2.2 节 还 大 致 介绍 了 AMQP 命令 以 及 与 
RabbitMQ 客户 端 中 方法 如 何 一 一 对 应 ， 包 括 对 各 个 整个 生产 消费 消息 的 AMQP 命令 的 流程 介 
绍 。 最 后 展示 了 AMQP 0-9-1 中 常用 的 命令 与 RabbitMQ 客户 端 中 方法 的 映射 关系 。 
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RabbitMQ Java 客户 端 使 用 com.zabbitmq.client 作 为 顶级 包 名 ,关键 的 Class 和 Interface 
有 Channel. Connection. ConnectionFactory. Consumer 等 。AMQP 协议 层面 的 操作 
通过 Channel 接口 实现 。Connection 是 用 来 开启 Channel (信道 ) 的 ， 可 以 注册 事件 处 理 
器 , 也 可 以 在 应 用 结束 时 关闭 连接 。 与 RabbitMQ 相关 的 开发 工作 , 基本 上 也 是 围绕 Connection 
和 Channel 这 两 个 类 展开 的 。 本 章 按照 一 个 完整 的 运转 流程 进行 讲解 ， 详 细 内 容 有 这 几 点 : dE 
接 、 交 换 器 /队列 的 创建 与 绑 定 、 发 送 消息 、 消 费 消 息 、 消 费 消息 的 确认 和 关闭 连接 。 
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3.1 连接 RabbitMQ 





下 面 的 代码 〈 代 码 清单 3-1) 用 来 在 给 定 的 参数 (OP 地 址 、 端 口号 、 用 户 名 、 密 码 等 ) 下 
连接 RabbitMQ: 





ConnectionFactory factory = new ConnectionFactory(); 
factory.setUsername (USERNAME) ; 

factory.setPassword (PASSWORD); 
factory.setVirtualHost (virtualHost); 
factory.setHost(IP ADDRESS); 

factory.setPort (PORT); 

Connection conn - factory.newConnection(); 


也 可 以 选择 使 用 URI 的 方式 来 实现 ， 示 例如 代码 清单 3-2 所 示 。 





ConnectionFactory factory = new ConnectionFactory(); 
factory.setUri ("amqp://userName:passwordG8ipAddress:portNumber/virtualHost"); 
Connection conn = factory.newConnection(); 


Connection 接口 被 用 来 创建 一 个 Channel: 


Channel channel = conn.createChannel(); 

在 创建 之 后 ，Channel 可 以 用 来 发 送 或 者 接收 消息 了 。 

注意 要 点 : 

Connection 可 以 用 来 创建 多 个 Channel 实例 ， 但 是 Channel 实例 不 能 在 线程 间 共 享 ， 
应 用 程序 应 该 为 每 一 个 线程 开辟 一 个 Channe1。 某 些 情况 下 Channel 的 操作 可 以 并 发 运行 , 但 
是 在 其 他 情况 下 会 导致 在 网 络 上 出 现 错误 的 通信 帧 交错 ， 同 时 也 会 影响 发 送 方 确认 (publisher 
confirm ) 机 制 的 运行 (详细 可 以 参考 4.8 节 ), 所 以 多 线程 间 共 享 Channel 实例 是 非 线程 安全 的 。 

channel 或 者 Connection 中 有 个 isopen 方 法 可 以 用 来 检测 其 是 否 已 处 于 开启 状态 ( 关 


于 Channel 或 者 Connection 的 状态 可 以 参考 3.6 节 )。 但 并 不 推荐 在 生产 环境 的 代码 上 使 用 
isOpen 方法 ， 这 个 方法 的 返回 值 依赖 于 shutdowncause (参考 下 面 的 代码 ) 的 存在 ， 有 可 
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能 会 产生 竞争 ， 代 码 清单 3-3 是 isopen 方法 的 源码 : 





public boolean isOpen() { 
synchronized(this.monitor) ( 
return this.shutdownCause -- null; 


) 
) 


错误 地 使 用 isopen 方法 示例 代码 如 代码 清 


3-4 所 示 。 


Pu 





public void brokenMethod (Channel channel) 
( 
if (channel.isOpen()) 
{ 
// The following code depends on the channel being in open state. 
// However there is a possibility of the change in the channel state 
// between isOpen() and basicQos (1) call 


channel.basicQos (1); 
} 


通常 情况 下 ， 在 调用 createxxx 或 者 newXXX 方法 之 后 ， 我 们 可 以 简单 地 认为 
Connection 或 者 Channel 已 经 成 功 地 处 于 开启 状态 ， 而 并 不 会 在 代码 中 使 用 isopen 这 个 
检测 方法 。 如 果 在 使 用 Channel 的 时 候 其 已 经 处 于 关闭 状态 ， 那 么 程序 会 抛 出 一 个 
com.rabbitmq.client.ShutdownSignalException, 我们 只 需 捕 获 这 个 异常 即 可 。 当 
然 同 时 也 要 试 着 捕获 IOException 或 者 SocketException, 以 防 Connection 意外 关闭 。 
示例 代码 如 代码 清单 3-5 所 示 。 


public void validMethod (Channel channel) 
{ 
try { 


channel.basicQos (1); 
) catch (ShutdownSignalException sse) ( 
// possibly check if channel was closed 
// by the time we started action and reasons for 
// closing it 
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) catch (IOException ioe) { 
// check why connection was closed 


3.2 ”使 用 交换 器 和 队列 


交换 器 和 队列 是 AMQP 中 high-level 层面 的 构建 模块 ， 应 用 程序 需 确保 在 使 用 它们 的 时 候 
就 已 经 存在 了 ， 在 使 用 之 前 需要 先 声明 (declare) 它们 。 


代码 清单 3-6 演示 了 如 何 声明 一 个 交换 器 和 队列 : 





channel.exchangeDeclare (exchangeName, "direct", true); 
String queueName = channel.queueDeclare().getQueue(); 
channel.queueBind(queueName, exchangeName, routingKey); 


上 面 创 建 了 一 个 持久 化 的 、 非 自动 删除 的 、 绑 定 类 型 为 direct 的 交换 器 ， 同 时 也 创建 了 一 
个 非 持久 化 的 、 排 他 的 、 自 动 删除 的 队列 《此 队列 的 名 称 由 RabbitMQ 自动 生成 )。 这 里 的 交换 
器 和 队列 也 都 没有 设置 特殊 的 参数 。 


上 面 的 代码 也 展示 了 如 何 使 用 路 由 键 将 队列 和 交换 器 绑 定 起 来 。 上 面 声明 的 队列 具备 如 下 
特性 : 只 对 当前 应 用 中 同一 个 Connection 层面 可 用 , 同一 个 Connection 的 不 同 Channel 
可 共用 ， 并 且 也 会 在 应 用 连接 断 开 时 自动 删除 。 


如 果 要 在 应 用 中 共享 一 个 队列 ， 可 以 做 如 下 声明 ， 如 代码 清单 3-7 所 示 。 











channel.exchangeDeclare (exchangeName, "direct", true); 
channel.queueDeclare(queueName, true, false, false, null); 
channel.queueBind(queueName, exchangeName, routingKey); 


这 里 的 队列 被 声明 为 持久 化 的 、 非 排他 的 、 非 自动 删除 的 ， 而 且 也 被 分 配 男 一 个 确定 的 已 
知 的 名 称 〔 由 客户 端 分 配 而 非 RabbitMQ 自动 生成 )。 


注意 :Channel 的 API 方 法 都 是 可 以 重 载 的 ,比如 exchangeDeclare、queueDeclare。 
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根据 参数 不 同 ， 可 以 有 不 同 的 重 载 形式 ， 根 据 自身 的 需要 进行 调用 。 


生产 者 和 消费 者 都 可 以 声明 一 个 交换 器 或 者 队列 。 如 果 尝 试 声明 一 个 已 经 存在 的 交换 器 或 
者 队列 ， 只 要 声明 的 参数 完全 匹配 现存 的 交换 器 或 者 队列 ，RabbitMQ 就 可 以 什么 都 不 做 ， 并 成 
功 返 回 。 如 果 声明 的 参数 不 匹配 则 会 抛 出 异常 。 


Di 


exchangeDeclare 有 多 个 重 载 方法 ， 这 些 重 载 方 法 都 是 由 下 面 这 个 方法 中 缺 省 的 某 些 参 
数 构成 的 。 
Exchange.DeclareOk exchangeDeclare(String exchange, 
String type, boolean durable, 
boolean autoDelete, boolean internal, 
Map«String, Object» arguments) throws IOException; 
这 个 方法 的 返回 值 是 Exchange.DeclareOoK， 用 来 标识 成 功 声 明了 一 个 交换 器 。 
各 个 参数 详细 说 明 如 下 所 述 。 
信 exchange: 交换 器 的 名 称 。 
* type: 交换 器 的 类 型 ， 常 见 的 如 fanout、direct、topic， 详 情 参见 2.1.4 节 。 


信 durable: 设置 是 否 持久 化 。qurable 设置 为 true 表示 持久 化 ， 反 之 是 非 持久 化 。 持 
久 化 可 以 将 交换 器 存盘 ， 在 服务 器 重启 的 时 候 不 会 丢失 相关 信息 。 


信 autoDelete: 设置 是 否 自动 删除 。autoDelete 设置 为 true 则 表示 自动 删除 。 自 动 
删除 的 前 提 是 至 少 有 一 个 队列 或 者 交换 器 与 这 个 交换 器 绑 定 , 之 后 所 有 与 这 个 交换 器 绑 
定 的 队列 或 者 交换 器 都 与 此 解 绑 。 注 意 不 能 错误 地 把 这 个 参数 理解 为 :“ 当 与 此 交换 器 
连接 的 客户 端 都 断 开 时 ，RabbitMQ 会 自动 删除 本 交换 器 ”。 


* internal: 设置 是 否 是 内 置 的 。 如 果 设 置 为 tue， 则 表示 是 内 置 的 交换 器 ， 客 户 端 程 
序 无 法 直接 发 送 消息 到 这 个 交换 器 中 ， 只 能 通过 交换 器 路 由 到 交换 器 这 种 方式 。 


* argument: 其 他 一 些 结构 化 参数 ， 比 如 alternate-exchange (有 关 alternate- 
exchange 的 详情 可 以 参考 4.1.3 节 )。 
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exchangeDeclare 的 其 他 重 载 方法 如 下 : 


(1) Exchange.DeclareOk exchangeDeclare(String exchange, String type) throws 


IOException; 


(2) Exchange.DeclareOk exchangeDeclare(String exchange, String type, boolean 


durable) throws IOException; 


(3) Exchange.DeclareOk exchangeDeclare(String exchange, String type, boolean 


durable, boolean autoDelete, Map«String, Object» arguments) throws IOException; 


与 此 对 应 的 ， 将 第 二 个 参数 String type H BuiltInExchangeType type 对 应 的 
几 个 重 载 方法 (不 常用 ): 


(1) Exchange.DeclareOk exchangeDeclare (String exchange, BuiltinExchangeType 


type) throws IOException; 


(2) Exchange.DeclareOk exchangeDeclare(String exchange, BuiltinExchangeType 


type, boolean durable) throws IOException; 


(3) Exchange.DeclareOk exchangeDeclare(String exchange, BuiltinExchangeType 
type, boolean durable, boolean autoDelete, Map«String, Object» arguments) throws 


IOException; 


(4) Exchange.DeclareOk exchangeDeclare (String exchange, BuiltinExchangeType 
type, boolean durable, boolean autoDelete, boolean internal, Map«String, Object» 


arguments) throws IOException; 


与 exchangeDeclare 师 出 同门 的 还 有 几 个 方法 ,比如 exchangeDeclareNoWait 方 法 ， 
具体 定义 如 下 (当然 也 有 BuiltExchangeType 版 的 ， 这 里 就 不 展开 了 ): 


void exchangeDeclareNoWait (String exchange, 
String type, 
boolean durable, 
boolean autoDelete, 
boolean internal, 
Map<String, Object> arguments) throws IOException; 


这 个 exchangeDeclareNoWait 比 exchangeDeclare 多 设置 了 一 个 nowait 参数 ， 
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这 个 nowait 参数 指 的 是 AMQP 中 Exchange .Declare 命令 的 参数 , 意思 是 不 需要 服务 器 返 
回 ， 注 意 这 个 方法 的 返回 值 是 void， 而 普通 的 exchangeDeclare 方法 的 返回 值 是 
Exchange.DeclareOk, 意思 是 在 客户 端 声明 了 一 个 交换 器 之 后 ， 需 要 等 待 服务 器 的 返回 〈 服 
务 器 会 返回 Exchange.Declare-Ok 这 个 AMQP 命令 )。 


针对 “exchangeDeclareNoWait 不 需要 服务 器 任何 返回 值 ” 这 一 点 , 考虑 这 样 一 种 情况 ， 
在 声明 完 一 个 交换 器 之 后 (实际 服务 器 还 并 未 完成 交换 器 的 创建 )， 那 么 此 时 客户 端 紧 接着 使 用 
这 个 交换 器 ， 必 然 会 发 生 异 常 。 如 果 没 有 特殊 的 缘由 和 应 用 场景 ， 并 不 建议 使 用 这 个 方法 。 


这 里 还 有 师 出 同门 的 另 一 个 方法 exchangeDeclarePassive， 这 个 方法 的 定义 如 下 : 


Exchange.DeclareOk exchangeDeclarePassive(String name) throws IOException; 


这 个 方法 在 实际 应 用 过 程 中 还 是 非常 有 用 的 ， 它 主要 用 来 检测 相应 的 交换 器 是 否 存在 。 如 果 
存在 则 正常 返回 ， 如 果 不 存在 则 抛 出 异常 : 404 channel exception， 同 时 Channel 也 会 被 关闭 。 


有 声明 创建 交换 器 的 方法 ， 当 然 也 有 删除 交换 器 的 方法 。 相 应 的 方法 如 下 : 
(1) Exchange.DeleteOk exchangeDelete(String exchange) throws IOException; 


(2) void exchangeDeleteNoWait(String exchange, boolean ifUnused) throws 


IOException; 


(3) Exchange.DeleteOk exchangeDelete (String exchange, boolean ifUnused) throws 


IOException; 


其 中 exchange 表示 交换 器 的 名 称 ,而 ifUnused 用 来 设置 是 否 在 交换 器 没有 被 使 用 的 情 
况 下 删除 。 如 果 isUnused 设置 为 tue， 则 只 有 在 此 交换 器 没有 被 使 用 的 情况 下 才 会 被 删除 ; 
如 果 设 置 false， 则 无 论 如 何 这 个 交换 器 都 要 被 删除 。 


ae 


queueDeclare 相对 于 exchangeDeclare 方法 而 言 ， 重 载 方法 的 个 数 就 少 很 多 ， 它 只 
有 两 个 重 载 方法 : 


(1) Queue.DeclareOk queueDeclare() throws IOException; 
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(2) Queue.DeclareOk queueDeclare (String queue, boolean durable, boolean exclusive, 


boolean autoDelete, Map«String, Object» arguments) throws IOException; 


不 带 任何 参数 的 queueDeclare 方法 默认 创建 一 个 由 RabbitMQ 命名 的 〈 类 似 这 种 
amq.gen-LhQzlgv3GhDOv8PIDabOXA 名 称 ， 这 种 队列 也 称 之 为 匿名 队列 )、 排 他 的 、 自 动 删除 
的 、 非 持久 化 的 队列 。 


方法 的 参数 详细 说 明 如 下 所 述 。 


个 
个 


dueue: 队列 的 名 称 。 


durable: 设置 是 否 持久 化 。 为 true 则 设置 队列 为 持久 化 。 持 久 化 的 队列 会 存盘 ， 在 
服务 器 重启 的 时 候 可 以 保证 不 丢失 相关 信息 。 


exclusive: 设置 是 否 排他 。 为 true 则 设置 队列 为 排他 的 。 如 果 一 个 队列 被 声明 为 排 
他 队列 ， 该 队列 仅 对 首次 声明 它 的 连接 可 见 ， 并 在 连接 断 开 时 自动 删除 。 这 里 需要 注意 
三 点 : 排他 队列 是 基于 连接 〈Connection》 可 见 的 ， 同 一 个 连接 的 不 同 信道 《Channel) 
是 可 以 同时 访问 同一 连接 创建 的 排他 队列 ;“ 首 次 ”是 指 如 果 一 个 连接 已 经 声明 了 一 个 
排他 队列 ， 其 他 连接 是 不 允许 建立 同名 的 排他 队列 的 ， 这 个 与 普通 队列 不 同 ; 即使 该 队 
列 是 持久 化 的 , 一 旦 连接 关闭 或 者 客户 端 退出 ,该 排他 队列 都 会 被 自动 删除 ， 这 种 队列 
适用 于 一 个 客户 端 同时 发 送 和 读 取消 息 的 应 用 场景 。 

autoDelete: 设 置 是 否 自动 删除 为 true 则 设置 队列 为 自动 删除 ,自动 删除 的 前 提 是 : 
至 少 有 一 个 消费 者 连接 到 这 个 队列 , 之 后 所 有 与 这 个 队列 连接 的 消费 者 都 断 开 时 , 才 会 
自动 删除 。 不 能 把 这 个 参数 错误 地 理解 为 :“ 当 连接 到 此 队列 的 所 有 客户 端 断 开 时 ， 这 
个 队列 自动 删除 ” 因为 生产 者 客户 端 创建 这 个 队列 ， 或 者 没有 消费 者 客户 端 与 这 个 队 
列 连接 时 ， 都 不 会 自动 删除 这 个 队列 。 

arguments: 设置 队列 的 其 他 一 些 参数 ， 如 x-message-ttl、x-expires、 
x-max-length. x-max-length-bytes. x-dead-letter-exchange. x-dead- 


letter-routing-key. x-max-priority 等 。 


注意 要 点 : 


生产 者 和 消费 者 都 能 够 使 用 queueDeclare 来 声明 一 个 队列 ， 但 是 如 果 消 费 者 在 同一 个 
信道 上 订阅 了 另 一 个 队列 ， 就 无 法 再 声明 队列 了 。 人 必须 先 取 消 订 阅 ， 然 后 将 信道 置 为 “传输 ” 
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模式 ， 之 后 才能 声明 队列 。 


对 应 于 exchangeDeclareNoWait 方法 ， 这 里 也 有 一 个 queueDeclareNoWait 方法 : 


void queueDeclareNoWait(String queue, boolean durable, boolean exclusive, 
boolean autoDelete, Map«String, Object» arguments) throws IOException; 


方法 的 返回 值 也 是 void， 表 示 不 需要 服务 端的 任何 返回 。 同 样 也 需要 注意 ， 在 调用 完 
queueDeclareNoWait 方法 之 后 ， 紧 接着 使 用 声明 的 队列 时 有 可 能 会 发 生 异 常情 况 。 

同样 这 里 还 有 一 个 queueDeclarePassive 的 方法 ， 也 比较 常用 。 这 个 方法 用 来 检测 相 
应 的 队列 是 否 存在 。 如 果 存 在 则 正常 返回 ， 如 果 不 存在 则 抛 出 异常 : 404 channel exception, F] 
时 Channel 也 会 被 关闭 。 方 法 定义 如 下 : 


Queue.DeclareOk queueDeclarePassive(String queue) throws IOException; 
与 交换 器 对 应 ， 关 于 队列 也 有 删除 的 相应 方法 : 
(1) Queue.DeleteOk queueDelete(String queue) throws IOException; 


(2) Queue.DeleteOk queueDelete(String queue, boolean ifUnused, boolean ifEmpty) 


throws IOException; 


(3) void queueDeleteNoWait(String queue, boolean ifUnused, boolean ifEmpty) 


throws IOException; 


其 中 queue 表示 队列 的 名 称 ，ifUnused 可 以 参考 上 一 小 节 的 交换 器 。ifEmpty 设置 为 
true 表示 在 队列 为 空 〈 队 列 里 面 没有 任何 消息 堆积 ) 的 情况 下 才能 够 删除 。 


与 队列 相关 的 还 有 一 个 有 意思 的 方法 一 一 queuePurge， 区 别 于 queueDelete， 这 个 方 
法 用 来 清空 队列 中 的 内 容 ， 而 不 删除 队列 本 身 ， 具 体 定义 如 下 : 


Queue .PurgeOk queuePurge (String queue) throws IOException; 


3.2.3 queueBind 方法 详解 





将 队列 和 交换 器 绑 定 的 方法 如 下 ， 可 以 与 前 两 节 中 的 方法 定义 进行 类 比 。 


(1) Queue.BindOk queueBind(String queue, String exchange, String routingKey) 
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throws IOException; 


(2) Queue.BindOk queueBind(String queue, String exchange, String routingKey, 


Map«String, Object» arguments) throws IOException; 


(3) void queueBindNoWait (String queue, String exchange, String routingKey, 


Map«String, Object» arguments) throws IOException; 
方法 中 涉及 的 参数 详解 。 
* queue: 队列 名 称 ; 
分 exchange: 交换 器 的 名 称 ; 
* routingKey: 用 来 绑 定 队列 和 交换 器 的 路 由 键 ; 
* argument: 定义 绑 定 的 一 些 参数 。 


不 仅 可 以 将 队列 和 交换 器 绑 定 起 来 ， 也 可 以 将 已 经 被 绑 定 的 队列 和 交换 器 进行 解 绑 。 有 具体 
方法 可 以 参考 如 下 (具体 的 参数 解释 可 以 参考 前 面 的 内 容 ， 这 里 不 再 资 述 ): 


(1) Queue.UnbindOk queueUnbind (String queue, String exchange, String routingKey) 


throws IOException; 


(2) Queue.UnbindOk queueUnbind (String queue, String exchange, String routingKey, 


Map«String, Object» arguments) throws IOException; 


3.24 exchangeBind 方法 详解 


我 们 不 仅 可 以 将 交换 器 与 队列 绑 定 ， 也 可 以 将 交换 器 与 交换 器 绑 定 ， 后 者 和 前 者 的 用 法 如 
出 一 略 ， 相 应 的 方法 如 下 : 


(1) Exchange.BindOk exchangeBind(String destination, String source, String 


routingKey) throws IOException; 


(2) Exchange.BindOk exchangeBind(String destination, String source, String 


routingKey, Map«String, Object» arguments) throws IOException; 
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(3) void exchangeBindNoWait (String destination, String source, String routingKey, 


Map«String, Object» arguments) throws IOException; 


方法 中 的 参数 可 以 参考 32.1 WH exchangeDeclare 方法 。 绑 定之 后 ， 消 息 从 source 交 
换 器 转发 到 destination 交换 器 ， 某 种 程度 上 来 说 destination 交换 器 可 以 看 作 一 个 队列 。 示 例 代 
码 如 代码 清单 3-8 所 示 。 





channel.exchangeDeclare("source", "direct", false, true, null); 
channel.exchangeDeclare("destination", "fanout", false, true, null); 


channel.exchangeBind("destination", "source", "exKey"); 
channel.queueDeclare("queue", false, false, true, null); 
channel.queueBind("queue", "destination", ""); 
channel.basicPublish("source", "exKey", null, "exToExDemo".getBytes()); 


生产 者 发 送 消息 至 交换 器 source 中 ， 交 换 器 source 根据 路 由 键 找到 与 其 匹配 的 另 一 个 交换 
器 destination， 并 把 消息 转发 到 destination 中 ， 进 而 存储 在 destination 绑 定 的 队列 queue 中 ， 可 
参考 图 3-1。 


namez"destination" 


typez"fanout" 
queue 
HE 
发 送 消息 
Producer 一 一 一 en 
namezsource 
Typez"direct" 


图 3-1 ”交换 器 与 交换 器 绑 定 


3.2.5 ” 何 时 创建 


RabbitMQ 的 消息 存储 在 队列 中 ,交换 器 的 使 用 并 不 真正 耗费 服务 器 的 性 能 ， 而 队列 会 。 如 
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果 要 衡量 RabbitMQ 当前 的 QPS! 只 需 看 队列 的 即 可 。 在 实际 业务 应 用 中 ， 需 要 对 所 创建 的 队列 
的 流量 、 内 存 占 用 及 网 卡 占 用 有 一 个 清晰 的 认 知 ， 预 估 其 平均 值 和 峰值 ， 以 便 在 固定 硬件 资源 
的 情况 下 能 够 进行 合理 有 效 的 分 配 。 

按照 RabbitMQ 官方 建议 ， 生 产 者 和 消费 者 都 应 该 尝试 创建 〈 这 里 指 声明 操作 ) 队列 。 这 是 
一 个 很 好 的 建议 ， 但 不 适用 于 所 有 的 情况 。 如 果 业 务 本 身 在 架构 设计 之 初 已 经 充分 地 预 估 了 队列 
的 使 用 情况 ， 完 全 可 以 在 业务 程序 上 线 之 前 在 服务 器 上 创建 好 〈 比 如 通过 页 面 管理 、RabbitMQ 
命令 或 者 更 好 的 是 从 配置 中 心 下 发 )， 这 样 业务 程序 也 可 以 免 去 声明 的 过 程 ， 直 接 使 用 即 可 。 

预先 创建 好 资源 还 有 一 个 好 处 是 ， 可 以 确保 交换 器 和 队列 之 间 正 确 地 绑 定 匹 配 。 很 多 时 候 ， 
由 于 人 为 因素 、 代 码 缺 陷 等 ， 发 送 消息 的 交换 器 并 没有 绑 定 任何 队列 ， 那 么 消息 将 会 丢失 ; 或 者 
交换 器 绑 定 了 某 个 队列 ， 但 是 发 送 消息 时 的 路 由 键 无 法 与 现存 的 队列 匹配 ， 那 么 消息 也 会 丢失 。 
当然 可 以 配合 mandatory 参数 或 者 备份 交换 器 (详细 可 参考 4.1 节 ) 来 提高 程序 的 健壮 性 。 

与 此 同时 ， 预 估 好 队列 的 使 用 情况 非常 重要 ， 如 果 在 后 期 运行 过 程 中 超过 预定 的 阔 值 ， 可 
以 根据 实际 情况 对 当前 集群 进行 扩容 或 者 将 相应 的 队列 迁移 到 其 他 集群 。 迁 移 的 过 程 也 可 以 对 
业务 程序 完全 透明 。 此 种 方法 也 更 有 利于 开发 和 运 维 分 工 ， 便 于 相应 资源 的 管理 。 

如 果 集 群 资源 充足 ， 而 即将 使 用 的 队列 所 占用 的 资源 又 在 可 控 的 范围 之 内 ， 为 了 增加 业务 
程序 的 灵活 性 ， 也 完全 可 以 在 业务 程序 中 声明 队列 。 

至 于 是 使 用 预先 分 配 创建 资源 的 静态 方式 还 是 动态 的 创建 方式 ， 需 要 从 业务 逻辑 本 身 、 公 
司 运 维 体 系 和 公司 硬件 资源 等 方面 考虑 。 


3.3 “发送 消息 


如 果 要 发 送 一 个 消息 ， 可 以 使 用 Channel 类 的 basicPublish 方法 ， 比 如 发 送 一 条 内 容 
为 “Hello World!” 的 消息 ， 参 考 如 下 : 


byte[] messageBodyBytes = "Hello, world!".getBytes(); 
channel.basicPublish(exchangeName, routingKey, null, messageBodyBytes); 


1 QPS， 即 每 秒 查询 率 ， 是 对 一 个 特定 的 查询 服务 器 在 规定 时 间 内 所 处 理 流量 多 少 的 衡量 标准 。 
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为 了 更 好 地 控制 发 送 ， 可 以 使 用 mandatory 这 个 参数 ， 或 者 可 以 发 送 一 些 特定 属性 的 信息 : 


channel.basicPublish(exchangeName, routingKey, mandatory, 
MessageProperties.PERSISTENT TEXT PLAIN, 
messageBodyBytes); 


上 面 这 行 代码 发 送 了 一 条 消息 ， 这 条 消息 的 投递 模式 〈delivery mode) 设置 为 2， 即 消息 会 
被 持久 化 〈 即 存 入 磁盘 ) 在 服务 器 中 。 同 时 这 条 消息 的 优先 级 〈priority) 设置 为 1，content-type 
为 “text/plain”。 可 以 自己 设 定 消息 的 属性 : 


channel.basicPublish(exchangeName, routingKey, 
new AMQP.BasicProperties.Builder() 

.contentType ("text/plain") 
.deliveryMode (2) 
.priority (1) 
.userId ("hidden") 
.build()), 
messageBodyBytes); 


也 可 以 发 送 一 条 带 有 headers 的 消息 : 


Map«String, Object» headers = new HashMap<String, Object> () 
headers.put("localtion", "here"); 
headers.put ("time","today"); 
channel.basicPublish(exchangeName, routingKey, 
new AMQP.BasicProperties.Builder() 

.headers (headers) 

.build() ) , 

messageBodyBytes); 


还 可 以 发 送 一 条 带 有 过 期 时 间 Cexpiration? 的 消息 : 


channel.basicPublish(exchangeName, routingKey, 
new AMQP.BasicProperties.Builder() 
.expiration ("60000") 
.build()), 
messageBodyBytes); 


以 上 只 是 举例 , 由 于 篇 幅 关系 , 这 里 就 不 一 一 列举 所 有 的 可 能 情形 了 .对 于 basicPublish 
而 言 ， 有 几 个 重 载 方法 : 


(1) void basicPublish (String exchange, String routingKey, BasicProperties props, 


byte[] body) throws IOException; 


(2) void basicPublish(String exchange, String routingKey, boolean mandatory, 
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BasicProperties props, byte[] body) throws IOException; 


(3) void basicPublish(String exchange, String routingKey, boolean mandatory, 


boolean immediate, BasicProperties props, byte[] body) throws IOException; 
对 应 的 具体 参数 解释 如 下 所 述 。 


* exchange: 交换 器 的 名 称 , 指明 消息 需要 发 送 到 哪个 交换 器 中 。 如 果 设 置 为 空 字符 串 ， 
则 消息 会 被 发 送 到 RabbitMQ 默认 的 交换 器 中 。 


信 routingKey: 路 由 键 ， 交 换 器 根据 路 由 键 将 消息 存储 到 相应 的 队列 之 中 。 
$9 props: 消息 的 基本 属性 集 ， 其 包含 14 个 属性 成 员 ， 分 别 有 contentType、 


contentEncoding.headers (Map«String,Object»).deliveryMode.priority. 


correlationId.replyTo.expiration.messageId.timestamp,type.userId. 


appId、clusterId。 其 中 常用 的 几 种 都 在 上 面 的 示例 中 进行 了 演示 。 
信 byte[] body: 消息 体 (payload)， 真 正 需要 发 送 的 消息 。 


信 mandatory 和 immediate 的 详细 内 容 请 参考 4.1 节 。 


3.4 消费 消息 
RabbitMQ 的 消费 模式 分 两 种 : 推 (Push 模式 和 拉 (Pull) 模 式 。 推 模式 采用 Basic.Consume 
进行 消费 ， 而 拉 模 式 则 是 调用 Basic .Get 进行 消费 。 
3.4.4 TER 


在 推 模式 中 ， 可 以 通过 持续 订阅 的 方式 来 消费 消息 ， 使 用 到 的 相关 类 有 : 


import com.rabbitmq.client.Consumer; 
import com.rabbitmq.client.DefaultConsumer; 


接收 消息 一 般 通过 实现 Consumer 接口 或 者 继承 DefaultConsumer 类 来 实现 。 当 调用 
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Ej Consumer 相关 的 API 方法 时 ， 不 同 的 订阅 采用 不 同 的 消费 者 标签 (consumerTag) 来 区 
分 彼此 ， 在 同一 个 Channel 中 的 消费 者 也 需要 通过 唯一 的 消费 者 标签 以 作 区 分 ， 关 键 消费 代 
码 如 代码 清单 3-9 所 示 。 





boolean autoAck = false; 
channel.basicQos (64); 
channel.basicConsume (queueName, autoAck, "myConsumerTag", 
new DefaultConsumer (channel) { 
GOverride 
public void handleDelivery(String consumerTag, 
Envelope envelope, 
AMQP.BasicProperties properties, 
byte[] body) 
throws IOException 


String routingKey = envelope.getRoutingKey(); 
String contentType = properties.getContentType(); 
long deliveryTag = envelope.getDeliveryTag(); 
// (process the message components here ...) 
channel.basicAck(deliveryTag, false); 
) 
)); 


注意 ， 上 面 代码 中 显 式 地 设置 autoAck 为 false， 然 后 在 接收 到 消息 之 后 进行 显 式 ack 操 
作 〈channel.basicRck ) 对 于 消费 者 来 说 这 个 设置 是 非常 必要 的 ， 可 以 防止 消息 不 必要 地 


EK. 
Channel 类 中 pasicConsume 方法 有 如 下 几 种 形式 : 


(1) String basicConsume(String queue, Consumer callback) throws IOException; 


(2) String basicConsume (String queue, boolean autoAck, Consumer callback) throws 


IOException; 


(3) String basicConsume (String queue, boolean autoAck, Map«String, Object» 


arguments, Consumer callback) throws IOException; 


(4) String basicConsume (String queue, boolean autoAck, String consumerTag, 


Consumer callback) throws IOException; 
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(5) String basicConsume(String queue, boolean autoAck, String consumerTag, 


boolean noLocal, boolean exclusive, Map«String, Object» arguments, Consumer callback) 


throws IOException; 


其 对 应 的 参数 说 明 如 下 所 述 。 


^ 
+ 
á 


分 + 


queue: 队列 的 名 称 ; 
autoAck: 设置 是 否 自动 确认 。 建 议 设 成 false， 即 不 自动 确认 ; 
consumerTag: 消费 者 标签 ， 用 来 区 分 多 个 消费 者 ; 


noLocal: 设置 为 true 则 表示 不 能 将 同一 个 Connection 中 生产 者 发 送 的 消息 传送 给 
这 个 Connection 中 的 消费 者 ; 


exclusive: 设置 是 否 排他 ; 
arguments: 设置 消费 者 的 其 他 参数 ; 


callback: 设置 消费 者 的 回调 函数 。 用 来 处 理 RabbitMQ 推送 过 来 的 消息 ， 比 如 
DefaultConsumer， 使 用 时 需要 客户 端 重 写 (overide) 其 中 的 方法 。 


对 于 消费 者 客户 端 来 说 重 写 handleDelivery 方法 是 十 分 方便 的 。 更 复杂 的 消费 者 客户 
端 会 重 写 更 多 的 方法 ， 有 具体 如 下 : 


void handleConsumeOk(String consumerTag); 

void handleCancelOk(String consumerTag); 

void handleCancel(String consumerTag) throws IOException; 

void handleShutdownSignal(String consumerTag, ShutdownSignalException sig); 
void handleRecoverOk(String consumerTag); 


比如 handleShutdownSignal 方 法 , 当 Channel 或 者 Connection 关 闭 的 时 候 会 调用 。 
再 者 ，handleConsumeOk 方法 会 在 其 他 方法 之 前 调用 ， 返 回 消费 者 标签 。 


重 写 handleCancelOk 和 handleCancel 方法 ， 这 样 消费 端 可 以 在 显 式 地 或 者 隐 式 地 取 
消 订 阅 的 时 候 调 用 。 也 可 以 通过 channel.basicCancel 方法 来 显 式 地 取消 一 个 消费 者 的 订阅 : 


channel.basicCancel (consumerTag); 


注意 上 面 这 行 代码 会 首先 触发 nandleConsumerOk 方法 ， 之 后 触发 handleDelivery 
方法 ， 最 后 才 触 发 handleCancelOk 方法 。 
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和 生产 者 一 样 , 消费 者 客户 端 同样 需要 考虑 线程 安全 的 问题 。 消费 者 客户 端的 这 些 callback 
会 被 分 配 到 与 channel 不 同 的 线程 池上 ， 这 意味 着 消费 者 客户 端 可 以 安全 地 调用 这 些 阻 塞 方 
法 ， 比 如 channel.queueDeclare、channel.basicCancel 等 。 

每 个 Channel 都 拥有 自己 独立 的 线程 。 最 常用 的 做 法 是 一 个 Channel 对 应 一 个 消费 者 ， 
也 就 是 意味 着 消费 者 彼此 之 间 没 有 任何 关联 。 当 然 也 可 以 在 一 个 Channel 中 维持 多 个 消费 者 ， 
但 是 要 注意 一 个 问题 ， 如 果 Channel 中 的 一 个 消费 者 一 直 在 运行 ， 那 么 其 他 消费 者 的 callback 
会 被 “耽搁 ”。 


3.4.2 dux 


这 里 讲 一 下 拉 模 式 的 消费 方式 。 通 过 channel.basicGet 方法 可 以 单条 地 获取 消息 ， 其 
返回 值 是 GetRespone。Channel 类 的 basicGet 方法 没有 其 他 重 载 方法 ， 只 有 : 


GetResponse basicGet(String queue, boolean autoAck) throws IOException; 


其 中 queue 代表 队列 的 名 称 ， 如 果 设 置 autoAck 为 false， 那 么 同样 需要 调用 
 channel.basicAck 来 确认 消息 已 被 成 功 接收 。 





GetResponse response = channel.basicGet(QUEUE NAME, false); 
System.out.println(new String(response.getBody())); 
channel.basicAck(response.getEnvelope().getDeliveryTag(),false); 


222 节 中 的 消费 者 流传 过 程 指 的 是 推 模式 , 这 里 采用 的 拉 模 式 的 消费 方式 如 图 3-2 所 示 ( 只 
展示 消费 的 部 分 )。 


注意 要 点 : 


Basic.Consume 将 信道 (Channel) 置 为 接收 模式 ， 直 到 取消 队列 的 订阅 为 止 。 在 接收 
模式 期 间 ,RabbitMQ 会 不 断 地 推送 消息 给 消费 者 , 当然 推送 消息 的 个 数 还 是 会 受到 Basic.Qos 
的 限制 。 如 果 只 想 从 队列 获得 单条 消息 而 不 是 持续 订阅 ， 建 议 还 是 使 用 Basic.Get 进行 消费 。 但 
是 不 能 将 Basic.Get 放 在 一 个 循环 里 来 代替 Basic.Consume, 这 样 做 会 严重 影响 RabbitMQ 
的 性 能 。 如 果 要 实现 高 吞吐 量 ， 消 费 者 理应 使 用 Basic.Consume 方法 。 
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此 处 省 略 Connection 和 channel 的 开启 | 


! Basic.Get ——— Rn TP RR 


«TIS —— ——— ——— »-* Basic.Get-OK 
《Basic.Get-Ok 会 携带 单条 消息 ) 


| Basic.Ack -.-.-.-.-.-.---.- — 


此 处 省 略 Connection 和 Channel 的 关闭 . 


3-2 hix 


35 消费 端的 确认 与 拒绝 





为 了 保证 消息 从 队列 可 靠 地 达到 消费 者 ，RabbitMQ 提供 了 消息 确认 机 制 (message 
acknowledgement)。 消 费 者 在 订阅 队列 时 ， 可 以 指定 autoAck 参数 ， 当 autoAck 等 于 false 
时 ，RabbitMQ 会 等 待 消费 者 显 式 地 回复 确认 信号 后 才 从 内 存 〈 或 者 磁盘 ) 中 移 去 消息 (实质 上 
是 先 打上 删除 标记 ， 之 后 再 删除 )。 当 autoAck 等 于 true 时 ，RabbitMQ 会 自动 把 发 送出 去 的 
消息 置 为 确认 , 然后 从 内 存 (或 者 磁盘 ) 中 删除 ， 而 不 管 消费 者 是 否 真正 地 消费 到 了 这 些 消息 。 


采用 消息 确认 机 制 后 ， 只 要 设置 autoAck 参数 为 false， 消 费 者 就 有 足够 的 时 间 处 理 消息 
(任务 )， 不 用 担心 处 理 消息 过 程 中 消费 者 进程 挂 掉 后 消息 丢失 的 问题 ， 因 为 RabbitMQ 会 一 直 
等 待 持 有 消息 直到 消费 者 显 式 调用 Basic.Ack 命令 为 止 。 


当 autoAck 参数 置 为 false, 对 于 RabbitMQ 服务 端 而 言 , 队列 中 的 消息 分 成 了 两 个 部 分 : 
一 部 分 是 等 待 投递 给 消费 者 的 消息 ， 一 部 分 是 已 经 投递 给 消费 者 ， 但 是 还 没有 收 到 消费 者 确认 
信号 的 消息 。 如 果 RabbitMQ 一 直 没 有 收 到 消费 者 的 确认 信号 ， 并 且 消 费 此 消息 的 消费 者 已 经 
断 开 连 接 ， 则 RabbitMQ 会 安排 该 消息 重新 进入 队列 ， 等 待 投递 给 下 一 个 消费 者 ， 当 然 也 有 可 
能 还 是 原来 的 那个 消费 者 。 
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RabbitMQ 不 会 为 未 确认 的 消息 设置 过 期 时 间 , 它 判 断 此 消息 是 否 需 要 重新 投递 给 消费 者 的 
唯一 依据 是 消费 该 消息 的 消费 者 连接 是 否 已 经 断 开 ， 这 么 设计 的 原因 是 RabbitMQ 人 允许 消费 者 
消费 一 条 消息 的 时 间 可 以 很 久 很 久 。 

RabbtiMQ 的 Web 管理 平台 (详细 参考 第 5.3 节 ) 上 可 以 看 到 当前 队列 中 的 “Ready” 状 态 


和 “Unacknowledged” 状 态 的 消息 数 ， 分 别 对 应 上 文中 的 等 待 投递 给 消费 者 的 消息 数 和 已 经 投 
递 给 消费 者 但 是 未 收 到 确认 信号 的 消息 数 ， 参 考 图 3-3。 


Overview Messages Message rates 
Name Node Features State Ready  Unacked Total incoming deliver / get ack 
mena deme EE KERE E B diia ru iis T rs ; n eive Siae uua 


3-3 Web 管理 页 面 中 的 消息 信息 
也 可 以 通过 相应 的 命令 来 查看 上 述 信息 : 


[root(zhuzhonghua2-fqawb ~]# rabbitmqctl list queues name messages ready 
messages unacknowledged 

Listing queues ... 

queue 1 0 

queue demo0 0 


在 消费 者 接收 到 消息 后 ， 如 果 想 明确 拒绝 当前 的 消息 而 不 是 确认 ， 那 么 应 该 怎么 做 呢 ? 
RabbitMQ 在 2.0.0 版 本 开始 引入 了 Basic.Reject 这 个 命令 ， 消 费 者 客户 端 可 以 调用 与 其 对 
应 的 channel.basicReject 方法 来 告诉 RabbitMQ 拒绝 这 个 消息 。 


Channel 类 中 的 basicReject 方法 定义 如 下 : 


void basicReject(long deliveryTag, boolean requeue) throws IOException; 


其 中 deliveryrTag 可 以 看 作 消 息 的 编号 ， 它 是 一 个 64 位 的 长 整 型 值 ， 最 大 值 是 
9223372036854775807。 如 果 requeue 参数 设置 为 tue， 则 RabbitMQ 会 重新 将 这 条 消息 存 入 
队列 ， 以 便 可 以 发 送 给 下 一 个 订阅 的 消费 者 ， 如 果 requeue 参数 设置 为 false， 则 RabbitMQ 
立即 会 把 消息 从 队列 中 移 除 ， 而 不 会 把 它 发 送 给 新 的 消费 者 。 


Basic.Reject 命令 一 次 只 能 拒绝 一 条 消息 ， 如 果 想 要 批量 拒绝 消息 ， 则 可 以 使 用 
Basic.Nack 这 个 命令 。 消 费 者 客户 端 可 以 调用 channel .basicNack 方法 来 实现 ， 方 法 定 
义 如 下 : 


void basicNack (long deliveryTag, boolean multiple, boolean requeue) throws 
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IOException; 

其 中 deliveryTag 和 requeue 的 含义 可 以 参考 basicReject Již. multiple 参数 
WB false 则 表示 拒绝 编号 为 deliveryTag 的 这 一 条 消息 ， 这 时 候 basicNack 和 
basicReject 方法 一 样 ， multiple 参数 设置 为 true 则 表示 拒绝 deliveryTag 编号 之 前 所 
有 未 被 当前 消费 者 确认 的 消息 。 

注意 要 点 : 


将 channel.basicReject 或 者 channel.basicNack 中 的 requeue 设置 为 false, 可 
以 启用 “ 死 信 队列 ”的 功能 。 死 信 队 列 可 以 通过 检测 被 拒绝 或 者 未 送 达 的 消息 来 追踪 问题 。 详 
细 内 容 可 以 参考 4.3 节 。 

对 于 requeue, AMQP 中 还 有 一 个 命令 Basic.Recover 具备 可 重 入 队列 的 特性 。 其 对 
应 的 客户 端 方法 为 : 


(1) Basic.RecoverOk basicRecover() throws IOException; 


(2) Basic.RecoverOk basicRecover (boolean requeue) throws IOException; 


这 个 channel.basicRecover 方法 用 来 请 求 RabbitMQ 重新 发 送 还 未 被 确认 的 消息 。 如 
果 requeue 参数 设置 为 true, 则 未 被 确认 的 消息 会 被 重新 加 入 到 队列 中 ,这样 对 于 同一 条 消息 
来 说 ， 可 能 会 被 分 配给 与 之 前 不 同 的 消费 者 。 如 果 requeue 参数 设置 为 false， 那 么 同一 条 消 
息 会 被 分 配给 与 之 前 相同 的 消费 者 。 默 认 情 况 下 ， 如 果 不 设置 requeue 这 个 参数 ， 相 当 于 


channel.basicRecover (true), Hl requeue 默认 为 true。 


3.6 关闭 连接 


在 应 用 程序 使 用 完 之 后 ， 需 要 关闭 连接 ， 释 放 资 源 : 


channel.close(); 
conn.close(); 


显 式 地 关闭 Channel 是 个 好 习惯 ， 但 这 不 是 必须 的 ， 在 Connection 关闭 的 时 候 ， 
Channel 也 会 自动 关闭 。 
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AMQP 协议 中 的 connection 和 Channel 采用 同样 的 方式 来 管理 网 络 失败 、 内 部 错误 和 
显 式 地 关闭 连接 。connection 和 Channel 所 具备 的 生命 周期 如 下 所 述 。 


* Open: 开启 状态 ， 代 表 当 前 对 象 可 以 使 用 。 


* Closing: 正在 关闭 状态 。 当 前 对 象 被 显 式 地 通知 调用 关闭 方法 (shutdown)， 这 样 
就 产生 了 一 个 关闭 请 求 让 其 内 部 对 象 进行 相应 的 操作 ， 并 等 待 这 些 关 闭 操作 的 完成 。 


* Closed: 已 经 关闭 状态 。 当 前 对 象 已 经 接收 到 所 有 的 内 部 对 象 已 完成 关闭 动作 的 通知 ， 
并 且 其 也 关闭 了 自身 。 


Connection 和 Channel 最 终 都 是 会 成 为 Closed 的 状态 ， 不 论 是 程序 正常 调用 的 关闭 
方法 ， 或 者 是 客户 端的 异常 ， 再 或 者 是 发 生 了 网 络 异 常 。 


在 Connection 和 Channel 中 ， 与 关闭 相关 的 方法 有 addShutdownListener 
(ShutdownListener listener) 和 removeShutdownListener (ShutdownListner 
listener). ?4 Connection 或 者 Channel 的 状态 转变 为 Closed 的 时 候 会 调用 
ShutdownListener。 而 且 如 果 将 一 个 ShutdownListener 注册 到 一 个 已 经 处 于 Closed 
状态 的 对 象 (这 里 特 指 Connection F Channel 对象) 时 ,会 立刻 调用 ShutdownListener。 


getCloseReason 方法 可 以 让 你 知道 对 象 关闭 的 原因 ; isopen 方法 检测 对 象 当 前 是 否 处 
于 开启 状态 ; close (int closeCode, String closeMessage) 方 法 显 式 地 通知 当前 对 象 
执行 关闭 操作 。 
有 关 ShutdownListener 的 使 用 可 以 参考 代码 清单 3-11。 





import com.rabbitmq.client.ShutdownSignalException; 
import com.rabbitmq.client.ShutdownListener; 


connection.addShutdownListener(new ShutdownListener() ( 
public void shutdownCompleted (ShutdownSignalException cause) 
{ 


) 
Fig 


当 触 发 ShutdownListener 的 时 候 ， 就 可 以 获取 到 ShutdownSignalException, 
这 个 ShutdownSignalException 包含 了 关闭 的 原因 , 这 里 原因 也 可 以 通过 调用 前 面 所 提 
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及 的 getCloseReason 方法 获取 。 


ShutdownSignalException 提供 了 多 个 方法 来 分 析 关 闭 的 原因 。isHardError 方法 
可 以 知道 是 Connection 的 还 是 channel 的 错误 ; getReason 方法 可 以 获取 cause 相关 的 
信息 ， 相 关 示 例 可 以 参考 代码 清单 3-12。 





public void shutdownCompleted (ShutdownSignalException cause) 
( 


if (cause.isHardError()) 

( 
Connection conn = (Connection)cause.getReference(); 
if (!cause.isInitiatedByApplication()) 
( 


Method reason - cause.getReason(); 
) 
) else ( 
Channel ch = (Channel)cause.getReference(); 


3.7 iE 


本 章 主要 介绍 RabbitMQ 客户 端 开发 的 简单 使 用 , 按照 一 个 生命 周期 的 维度 对 连接 、 创 建 、 
生产 、 消 费 和 关闭 等 几 个 方面 进行 笼统 的 介绍 ， 读 者 学 习 完 本 章 的 内 容 之 后 ， 就 能 够 有 效 地 进 
行 与 RabbitMQ 相关 的 开发 工作 。 知 是 行 之 始 ， 行 是 知之 成 ， 不 如 现在 动手 编写 几 个 程序 来 实 
践 一 下 吧 。 
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前 一 章 中 所 讲述 的 是 一 些 基 础 的 概念 及 使 用 方法 ， 比 如 创建 交换 器 、 队 列 和 绑 定 关系 等 。 
但 是 其 中 有 许多 细节 并 未 陈述 ， 对 使 用 过 程 中 的 一 些 “ 坑 ” 也 并 未 提 及 ， 一 些 高 级 用 法 也 并 未 
展现 ， 所 以 本 章 的 内 容 就 是 要 弥补 这 些 缺 憾 。 本 章 以 RabbitMQ 基础 使 用 知识 为 前 提 ， 阅 述 一 
些 更 具 特 色 的 细节 及 功能 ， 为 读者 更 进一步 地 掌握 RabbitMQ 提供 基准 。 
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4.1 ”消息 何去何从 


mandatory fll immediate 是 channel.basicPublish 方法 中 的 两 个 参数 ， 它 们 都 有 
当 消 息 传递 过 程 中 不 可 达 目 的 地 时 将 消息 返回 给 生产 者 的 功能 。RabbitMQ 提供 的 备份 交换 器 
(Alternate Exchange) 可 以 将 未 能 被 交换 器 路 由 的 消息 〈 没 有 绑 定 队 列 或 者 没有 匹配 的 绑 定 ) 存 
储 起 来 ， 而 不 用 返回 给 客户 端 。 


对 于 初学 者 来 说 ， 特 别 容易 将 mandatory 和 immediate 这 两 个 参数 混淆 ， 而 对 于 备份 
交换 器 更 是 一 筹 莫 展 ， 本 章 对 此 一 一 展开 探讨 。 


4.1.1 mandatory 参数 





当 mandatory 参数 设 为 true 时 ， 交 换 器 无 法 根据 自身 的 类 型 和 路 由 键 找 到 一 个 符合 条 件 
的 队列 ， 那 么 RabbitMQ 会 调用 Basic.Return 命令 将 消息 返回 给 生产 者 。 当 mandatory 参 
数 设置 为 false 时 ， 出 现 上 述 情形 ， 则 消息 直接 被 丢弃 。 


那么 生产 者 如 何 获取 到 没有 被 正确 路 由 到 合适 队列 的 消息 呢 ?” 这 时 候 可 以 通过 调用 
channel.addReturnListener 来 添加 ReturnListener 监听 器 实现 。 


使 用 mandatory 参数 的 关键 代码 如 代码 清单 4-1 所 示 。 


channel.basicPublish (EXCHANGE NAME, "", true, 
MessageProperties.PERSISTENT TEXT PLAIN, 
"mandatory test".getBytes()); 
channel.addReturnListener(new ReturnListener() { 
public void handleReturn(int replyCode, String replyText, 
String exchange, String routingKey, 
AMQP.BasicProperties basicProperties, 
byte[] body) throws IOException ( 
String message = new String (body); 
System.out.println("Basic.Return 返回 的 结果 是 : "+message); 
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上 面 代 码 中 生产 者 没有 成 功 地 将 消息 路 由 到 队列 ， 此 时 RabbitMQ 会 通过 Basic.Return 
返回 “mandatory test” 这 条 消息 ， 之 后 生产 者 客户 端 通过 Returnbistener 监听 到 了 这 个 事 
件 ， 上 面 代 码 的 最 后 输出 应 该 是 “Basic.Retum 返回 的 结果 是 : mandatory test". 


从 AMQP 协议 层面 来 说 ， 其 对 应 的 流转 过 程 如 图 4-1 所 示 。 


! 此 处 省 略 Connection 和 channel 的 开启 : 
| ' 没有 路 由 到 
1 Basic.Publish -~:~ MÀ e c» Tad 任何 队列 
: be rererere Ver Basic.Return: 
《Basic.Return 会 携带 消息 ) | 
此 处 省 略 Connection 和 Channel 的 关闭 ' 


图 4-1 mandatory 参数 


4.1.2 immediate 参数 


当 immediate 参数 设 为 tue 时 ， 如 果 交 换 器 在 将 消息 路 由 到 队列 时 发 现 队 列 上 并 不 存在 
任何 消费 者 ， 那 么 这 条 消息 将 不 会 存 入 队列 中 。 当 与 路 由 键 匹配 的 所 有 队列 都 没有 消费 者 时 ， 
该 消息 会 通过 Basic.Return 返回 至 生产 者 。 

概括 来 说 ，mandatory 参数 告诉 服务 器 至 少将 该 消息 路 由 到 一 个 队列 中 ， 和 否则 将 消息 返 
回 给 生产 者 。immediate 参数 告诉 服务 器 ,如果 该 消息 关联 的 队列 上 有 消费 者 , 则 立刻 投递 ; 
如 果 所 有 匹配 的 队列 上 都 没有 消费 者 ， 则 直接 将 消息 返还 给 生产 者 ， 不 用 将 消息 存 入 队列 而 等 
待 消费 者 了 。 


RabbitMQ 3.0 版 本 开始 去 掉 了 对 immediate 参数 的 支持 ， 对 此 RabbitMQ 官方 解释 是 : 
immediate 参数 会 影响 镜像 队列 的 性 能 , 增加 了 代码 复杂 性 , 建议 采用 TTL A DLX 的 方法 蔡 
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Ro CAER TTL 和 DLX 的 介绍 请 分 别 参考 4.2 节 和 4.3 节 。) 


发 送 带 immediate 参数 (immediate 参数 设置 为 true) 的 Basic.Publish 客户 端 会 
报 如 下 异常 : 


[WARN] - [An unexpected connection driver error occured (Exception message: 
Connection reset)] - [com.rabbitmq.client.impl.ForgivingExceptionHandler:120] 


RabbitMQ 服务 端 会 报 如 下 异常 (查看 RabbitMQ 的 运行 日 志 ， 默 认 日 志 路 径 为 
SRABBITMQ HOME/var/log/rabbitmq/rabbit8 $HOSTNAME.10og?: 


-ERROR REPORT---- 25-May-2017::15:10:25 === 
Error on AMQP connection «0.25319.2» (192.168.0.2:55254-»192.168.0.3:5672, vhost: 
'/', user: 'root', state: running), channel 1:í(amqp error,not implemented," 


immediate-true",'basic.publish'] 


4.1.3 备份 交换 器 


备份 交换 器 , 英文 名 称 为 Alternate Exchange, 简称 AE, 或 者 更 直 白 地 称 之 为 “ 备 胎 交换 器 ”。 
生产 者 在 发 送 消息 的 时 候 如 果 不 设置 mandatory 参数 , 那么 消息 在 未 被 路 由 的 情况 下 将 会 丢失 ; 
如 果 设 置 了 mandatory 参数 ， 那 么 需要 添加 ReturnListene 的 编程 逻辑 ， 生 产 者 的 代码 将 
变 得 复杂 。 如 果 既 不 想 复 杂 化 生产 者 的 编程 逻辑 ， 又 不 想 消息 丢失 ， 那 么 可 以 使 用 备份 交换 器 ， 
这 样 可 以 将 未 被 路 由 的 消息 存储 在 RabbitMQ 中 ， 再 在 需要 的 时 候 去 处 理 这 些 消息 。 


可 以 通过 在 声明 交换 器 (调用 channel.exchangeDeclare 方法 ) 的 时 候 添 加 
alternate-exchange 参数 来 实现 , 也 可 以 通过 策略 (Policy, 详细 参考 6.3 节 ) 的 方式 实现 。 
如 果 两 者 同时 使 用 ， 则 前 者 的 优先 级 更 高 ， 会 覆盖 掉 Policy 的 设置 。 


使 用 参数 设置 的 关键 代码 如 代码 清单 4-2 所 示 。 





e COD tos Mu 


Map«String, Object» args = new HashMapcString, Object»(); 
args.put("alternate-exchange", "myAe"); 
channel.exchangeDeclare("normalExchange", "direct", true, false, args); 
channel.exchangeDeclare("myAe", "fanout", true, false, null); 
channel.queueDeclare("normalQueue", true, false, false, null); 
channel.queueBind("normalQueue", "normalExchange", "normalKey"); 
channel.queueDeclare("unroutedQueue", true, false, false, null); 
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channel.queueBind("unroutedQueue", "myAe", ""); 


上 面 的 代码 中 声明 了 两 个 交换 器 normalExchange 和 myAe， 分 别 绑 定 了 normalQueue 和 
unroutedQueue 这 两 个 队列 ， 同 时 将 myAe 设置 为 normalExchange 的 备份 交换 器 。 注 意 myAe 
的 交换 器 类 型 为 fanout。 


参考 图 4-2， 如 果 此 时 发 送 一 条 消息 到 normalExchange 上 ， 当 路 由 键 等 于 “normalKey” 的 
时 候 , 消息 能 正确 路 由 到 normalQueue 这 个 队列 中 。 如 果 路 由 键 设 为 其 他 值 ， 比 如 “errorKey”， 
即 消息 不 能 被 正确 地 路 由 到 与 normalExchange 绑 定 的 任何 队列 上 ， 此 时 就 会 发 送 给 myAe， 进 
而 发 送 到 unroutedQueue 这 个 队列 。 

name-"myAe" 


type-"fanout" 
unroutedQueue 


' 


`、@ 如 果 消 息 无 法 路 由 则 
、 发 送 给 备份 交换 器 


^ 


' GifWtExhangeitaép: — "9 e Queue 


Li 


,本 的 队列 则 将 消息 入 队 





发 送 消息 
Producer 


name=normalExchange 
type-*direct" 


图 4-2 备份 交换 器 


同样 ， 如 果 采 用 Policy 的 方式 来 设置 备份 交换 器 ， 可 以 参考 如 下 : 

rabbitmqctl set policy AE "^normalExchange$" ‘{"alternate-exchange": "myAE"}’ 

备份 交换 器 其 实 和 普通 的 交换 器 没有 太 大 的 区 别 , 为 了 方便 使 用 ,建议 设置 为 fanout 类 型 ， 
如 车 读者 想 设置 为 direct 或 者 topic 的 类 型 也 没有 什么 不 妥 。 需 要 注意 的 是 ， 消 息 被 重新 发 送 到 
备份 交换 器 时 的 路 由 键 和 从 生产 者 发 出 的 路 由 键 是 一 样 的 。 

考虑 这 样 一 种 情况 ， 如 果 备 份 交 换 器 的 类 型 是 direct, 并 且 有 一 个 与 其 绑 定 的 队列 ,假设 绑 
定 的 路 由 键 是 key1， 当 某 条 携带 路 由 键 为 key2 的 消息 被 转发 到 这 个 备份 交换 器 的 时 候 ， 备 份 
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交换 器 没有 匹配 到 合适 的 队列 ， 则 消息 丢失 。 如 果 消 息 携 带 的 路 由 键 为 key1， 则 可 以 存储 到 队 
列 中 。 


对 于 备份 交换 器 ， 总 结 了 以 下 几 种 特殊 情况 : 
€ 如 果 设 置 的 备份 交换 器 不 存在 ,客户 端 和 RabbitMQ 服务 端 都 不 会 有 异常 出 现 ， 此 时 消 


息 会 丢失 。 

令 如 果 备份 交换 器 没有 绑 定 任何 队列 ,客户 端 和 RabbitMQ 服务 端 都 不 会 有 异常 出 现 ， 此 
时 消息 会 丢失 。 

€ 如 果 备 份 交 换 器 没有 任何 匹配 的 队列 ， 客 户 端 和 RabbitMQ 服务 端 都 不 会 有 异常 出 现 ， 
此 时 消息 会 丢失 。 


信 如 果 备份 交 换 器 和 mandatory 参数 一 起 使 用 ， 那 么 mandatory 参数 无 效 。 


4.2 过 期 时 间 ( TTL) 





TTL, Time to Live 的 简称 ， 即 过 期 时 间 。RabbitMQ 可 以 对 消息 和 队列 设置 TTL. 


4.2.1 设置 消息 的 TTL 


目前 有 两 种 方法 可 以 设置 消息 的 TITL。 第 一 种 方法 是 通过 队列 属性 设置 ， 队 列 中 所 有 消息 
都 有 相同 的 过 期 时 间 。 第 二 种 方法 是 对 消息 本 身 进 行 单独 设置 ， 每 条 消息 的 TTL 可 以 不 同 。 如 
果 两 种 方法 一 起 使 用 ， 则 消息 的 TTL 以 两 者 之 间 较 小 的 那个 数值 为 准 。 消 息 在 队列 中 的 生存 时 
间 一 旦 超过 设置 的 TTL 值 时 ， 就 会 变 成 “ 死 信 ”(Dead Message)， 消 费 者 将 无 法 再 收 到 该 消息 
(这 点 不 是 绝对 的 ， 可 以 参考 43 节 )。 

通过 队列 属性 设置 消息 TTL 的 方法 是 在 channel.queueDeclare 方法 中 加 入 
x-message-ttl 参数 实现 的 ， 这 个 参数 的 单位 是 毫秒 。 


示例 代码 如 代码 清单 4-3 所 示 。 
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Map«String, Object» argss = new HashMap«String, Object»(); 
argss.put ("x-message-ttl",6000); 
channel.queueDeclare(queueName, durable, exclusive, autoDelete, argss); 


同时 也 可 以 通过 Policy 的 方式 来 设置 TTL， 示 例如 下 : 
rabbitmqctl set policy TTL ".*" '("message-ttl":60000)' --apply-to queues 
还 可 以 通过 调用 HTTP API 接口 设置 : 


$ curl -i -u root:root -H "content-type:application/json"-X PUT 
-d'("auto delete":false,"durable":true,"arguments":("x-message-ttl": 60000}}' 
http: //1localhost:15672/api/queues/(vhost) /(queuename) 


如 果 不 设 置 TTL， 则 表示 此 消息 不 会 过 期 ， 如 果 将 TTL 设置 为 0， 则 表示 除非 此 时 可 以 直 
接 将 消息 投递 到 消费 者 ， 和 否则 该 消息 会 被 立即 丢弃 ， 这 个 特性 可 以 部 分 替代 RabbitMQ 3.0 版 本 
之 前 的 immediate 参数 ， 之 所 以 部 分 代替 ， 是 因为 immediate 参数 在 投递 失败 时 会 用 
Basic.Return 将 消息 返回 〈 这 个 功能 可 以 用 死 信 队列 来 实现 ， 详 细 参 考 4.3 节 )。 


针对 每 条 消息 设置 TTL 的 方法 是 在 channel.basicPublish 方法 中 加 入 expiration 
的 属性 参数 ， 单 位 为 毫秒 。 


关键 代码 如 代码 清单 4-4 所 示 。 





AMQP.BasicProperties.Builder builder = new AMQP.BasicProperties.Builder(); 

builder.deliveryMode (2) ;// 持 久 化 消息 

builder.expiration("60000");// 设 置 TTL=60000ms 

AMQP.BasicProperties properties = builder.build(); 

channel.basicPublish (exchangeName, routingKey,mandatory,properties, 
"ttlTestMessage".getBytes()); 


也 可 以 使 用 如 代码 清单 4-5 所 示 的 方式 : 





AMQP.BasicProperties properties = new AMQP.BasicProperties(); 

Properties.setDeliveryMode (2); 

properties.setExpiration ("60000"); 

channel.basicPublish (exchangeName, routingKey,mandatory,properties, 
"ttlTestMessage".getBytes()); 


还 可 以 通过 HTTP API 接口 设置 : 
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$ curl -i -u root:root -H "content-type:application/json" -X POST -d 
'("properties":("expiration":"60000"],"routing key":"routingkey", 
"payload":"my body", 

"payload encoding":"string")' 
http://localhost:15672/api/exchanges/(vhost])/(exchangename)/publish 


对 于 第 一 种 设置 队列 TTL 属性 的 方法 ,一 旦 消息 过 期 ， 就 会 从 队列 中 抹 去 ， 而 在 第 二 种 方 
法 中 ， 即 使 消息 过 期 ， 也 不 会 马上 从 队列 中 抹 去 ， 因 为 每 条 消息 是 否 过 期 是 在 即将 投递 到 消费 
者 之 前 判定 的 。 


为 什么 这 两 种 方法 处 理 的 方式 不 一 样 ? 因为 第 一 种 方法 里 ， 队 列 中 已 过 期 的 消息 肯定 在 队 
列 头 部 ，RabbitMQ 只 要 定期 从 队 头 开始 扫描 是 否 有 过 期 的 消息 即 可 。 而 第 二 种 方法 里 ， 每 条 消 
息 的 过 期 时 间 不 同 ， 如 果 要 删除 所 有 过 期 消息 势必 要 扫描 整个 队列 ， 所 以 不 如 等 到 此 消息 即将 
被 消费 时 再 判定 是 否 过 期 ， 如 果 过 期 再 进行 删除 即 可 。 


4.2.2 ”设置 队列 的 TTL 


Ñt channel .queueDeclare 方 法 中 的 x-expires 参数 可 以 控制 队列 被 自动 删除 前 处 
于 未 使 用 状态 的 时 间 。 未 使 用 的 意思 是 队列 上 没有 任何 的 消费 者 ， 队 列 也 没有 被 重新 声明 ， 并 
且 在 过 期 时 间 段 内 也 未 调用 过 Basic .Get 命令 。 


设置 队列 里 的 TTL. 可 以 应 用 于 类 似 RPC 方式 的 回复 队列 ， 在 RPC 中 ， 许 多 队列 会 被 创建 
出 来 ， 但 是 却 是 未 被 使 用 的 。 

RabbitMQ 会 确保 在 过 期 时 间 到 达 后 将 队列 删除 ， 但 是 不 保障 删除 的 动作 有 多 及 时 。 在 
RabbitMQ 重启 后 ， 持 久 化 的 队列 的 过 期 时 间 会 被 重新 计算 。 

用 于 表示 过 期 时 间 的 x-expires 参数 以 毫秒 为 单位 ， 并 且 服 从 和 x-message-tt1 一 样 
的 约束 条 件 ， 不 过 不 能 设置 为 0。 比 如 该 参数 设置 为 1000， 则 表示 该 队列 如 果 在 1 秒 钟 之 内 未 
使 用 则 会 被 删除 。 

代码 清单 4-6 演示 了 创建 一 个 过 期 时 间 为 30 分 钟 的 队列 : 


UNITA AC THES 





Map«String, Object» args = new HashMap«String, Object»(); 
args.put("x-expires", 1800000); 
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channel.queueDeclare("myqueue", false, false, false, args); 


4.3 JUEZ 


DLX， 全 称 为 Dead-Letter-Exchange， 可 以 称 之 为 死 信 交 换 器 ， 也 有 人 称 之 为 死 信 邮 箱 。 当 
消息 在 一 个 队列 中 变 成 死 信 (dead message) 之 后 ， 它 能 被 重新 被 发 送 到 另 一 个 交换 器 中 ， 这 个 
交换 器 就 是 DLX， 绑 定 DLX 的 队列 就 称 之 为 死 信 队列 。 

消息 变 成 死 信 一 般 是 由 于 以 下 几 种 情况 : 

信 消息 被 拒绝 (Basic.Reject/Basic.Nack)， 并 且 设 置 requeue 参数 为 false; 

信 消息 过 期 ; 

信 队列 达到 最 大 长 度 。 

DLX 也 是 一 个 正常 的 交换 器 ， 和 一 般 的 交换 器 没有 区 别 ， 它 能 在 任何 的 队列 上 被 指定 ， 实 
际 上 就 是 设置 某 个 队列 的 属性 。 当 这 个 队列 中 存在 死 信 时 ，RabbitMQ 就 会 自动 地 将 这 个 消息 重 
新 发 布 到 设置 的 DLX 上 去 ， 进 而 被 路 由 到 另 一 个 队列 ， 即 死 信 队 列 。 可 以 监听 这 个 队列 中 的 消 
息 以 进行 相应 的 处 理 ， 这 个 特性 与 将 消息 的 TTL 设置 为 0 配合 使 用 可 以 弥补 immediate 参数 
的 功能 。 

通过 在 channel.queueDeclare 方法 中 设置 x-dead-letter-exchange 参数 来 为 这 
个 队列 添加 DLX 代码 清单 4-7 中 的 dlx_exchange) 








Map<String, Object» args = new HashMap<String, Object»(); 
args.put("x-dead-letter-exchange", " dlx exchange "); 
// 为 队列 myqueue 添加 DLX 


channel.queueDeclare("myqueue", false, false, false, args); 


也 可 以 为 这 个 DLX 指定 路 由 键 ， 如 果 没 有 特殊 指定 ， 则 使 用 原 队 列 的 路 由 键 : 


args.put("x-dead-letter-routing-key", "dlx-routing-key"); 


当然 这 里 也 可 以 通过 Policy 的 方式 设置 : 
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rabbitmqctl set policy DLX ".*" '("dead-letter-exchange":" dlx exchange "J' 
--apply-to queues 


下 面 创建 一 个 队列 ， 为 其 设置 TTL 和 DLX 等 ， 如 代码 清单 4-8 所 示 。 





channel.exchangeDeclare("exchange.dlx", "direct", true); 
channel.exchangeDeclare("exchange.normal", "fanout", true); 
Map«String, Object» args = new HashMap<String Object»(); 
args.put("x-message-ttl", 10000); 
args.put("x-dead-letter-exchange", "exchange.dlx"); 
args.put("x-dead-letter-routing-key", "routingkey"); 
channel.queueDeclare("queue.normal", true, false, false, args); 
channel.queueBind("queue.normal", "exchange.normal", ""); 
channel.queueDeclare("queue.dlx", true, false, false, null); 
channel.queueBind("queue.dlx", "exchange.dlx", "routingkey"); 
channel.basicPublish("exchange.normal", "rk", 
MessageProperties.PERSISTENT TEXT PLAIN, "dlx".getBytes()); 


这 里 创建 了 两 个 交换 器 exchange.normal 和 exchange.dlx， 分 别 绑 定 两 个 队列 queue.normal 
和 queue.dlx。 


由 Web 管理 页 面 (图 4-3) 可 以 看 出 ， 两 个 队列 都 被 标记 了 “D” 这 个 是 durable 的 缩写 ， 
即 设置 了 队列 持久 化 。queue.normal 这 个 队列 还 配置 了 TTL. DLX 和 DLK， 其 中 DLX 指 的 是 
x-dead-letter-routing-key 这 个 属性 。 





j Overview | Messages | Message rates 
Name | Features State Ready Unacked Total incoming deliver / get ack 
Te nt ; | 
—— | MES ——— n N 





图 4-3 队列 的 属性 展示 


参考 图 4-4， 生 产 者 首先 发 送 一 条 携带 路 由 键 为 “水” 的 消息 ， 然 后 经 过 交换 器 
exchange.normal 顺利 地 存储 到 队列 queue.normal 中 。 由 于 队列 queue.normal 设置 了 过 期 时 间 为 
10s, 在 这 10s 内 没有 消费 者 消费 这 条 消息 ， 那 么 判定 这 条 消息 为 过 期 。 由 于 设置 了 DLX， 过 期 
之 时 ， 消 息 被 丢 给 交换 器 exchange.dlx 中 ， 这 时 找到 与 exchange.dlx 匹配 的 队列 queue.dlx， 最 
后 消息 被 存储 在 queue.dlx 这 个 死 信 队 列 中 。 
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narme= "exchange .dlx” 
typez"direct" 


queue.dix 


I". 


x-dead-letter-exchangezexchange.dix 
x-dead-letter-routing-key-routingkey 






queue.normal 
发 送 消息 
Producer | —————» 


x-message-tti- 10000 
namez"exchange.normal" 
typez"fanout" 


4-4 死 信 队 列 


对 于 RabbitMQ 来 说 ，DLX 是 一 个 非常 有 用 的 特性 。 它 可 以 处 理 异 常情 况 下 ， 消 息 不 能 够 
被 消费 者 正确 消费 (消费 者 调用 了 Basic.Nack 或 者 Basic.Reject) 而 被 置 入 死 信 队 列 中 
的 情况 ， 后 续 分 析 程 序 可 以 通过 消费 这 个 死 信 队 列 中 的 内 容 来 分 析 当 时 所 遇 到 的 异常 情况 ， 进 
而 可 以 改善 和 优化 系统 。DLX 配合 TTL 使 用 还 可 以 实现 延迟 队列 的 功能 ， 详 细 请 看 下 一 节 。 


4.4 延迟 队列 


延迟 队列 存储 的 对 象 是 对 应 的 延迟 消息 ， 所 谓 “ 延 迟 消息 ”是 指 当 消 息 被 发 送 以 后 ， 并 不 
想 让 消费 者 立刻 拿 到 消息 ， 而 是 等 待 特定 时 间 后 ， 消 费 者 才能 拿 到 这 个 消息 进行 消费 。 


延迟 队列 的 使 用 场景 有 很 多 ， 比 如 : 


信 在 订单 系统 中 ， 一 个 用 户 下 单 之 后 通常 有 30 分 钟 的 时 间 进 行 支付 ， 如 果 30 分 钟 之 内 
没有 支付 成 功 ， 那 么 这 个 订单 将 进行 异常 处 理 ， 这 时 就 可 以 使 用 延迟 队列 来 处 理 这 些 
订单 了 。 

仿 用 户 和 希望 通过 手机 远程 遥控 家 里 的 智能 设备 在 指定 的 时 间 进 行 工作 。 这 时 候 就 可 以 将 
用 户 指令 发 送 到 延迟 队列 ， 当 指令 设 定 的 时 间 到 了 再 将 指令 推送 到 智能 设备 。 
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在 AMQP 协议 中 ， 或 者 RabbitMQ 本 身 没有 直接 支持 延迟 队列 的 功能 ， 但 是 可 以 通过 前 面 
所 介绍 的 DLX 和 TTL 模拟 出 延迟 队列 的 功能 。 


在 图 4-4 中 ， 不 仅 展 示 的 是 死 信 队列 的 用 法 ， 也 是 延迟 队列 的 用 法 ， 对 于 queue.dlx 这 个 死 
信 队 列 来 说 ， 同 样 可 以 看 作 延 迟 队 列 。 假 设 一 个 应 用 中 需要 将 每 条 消息 都 设置 为 10 秒 的 延迟 ， 
生产 者 通过 exchange.normal 这 个 交换 器 将 发 送 的 消息 存储 在 queue.normal 这 个 队列 中 。 消费 者 
订阅 的 并 非 是 queue.normal 这 个 队列 ,而 是 queue.dlx 这 个 队列 。 当 消息 从 queue.normal 这 个 队 
列 中 过 期 之 后 被 存 入 queue.dlx 这 个 队列 中 ， 消 费 者 就 恰巧 消费 到 了 延迟 10 秒 的 这 条 消息 。 


在 真实 应 用 中 ， 对 于 延迟 队列 可 以 根据 延迟 时 间 的 长 短 分 为 多 个 等 级 ， 一 般 分 为 5 秒 、10 
秒 、30 秒 、1 分 钟 、5 分 钟 、10 分 钟 、30 分 钟 、1 小 时 这 几 个 维度 ， 当 然 也 可 以 再 细 化 一 下 。 


参考 图 4-5， 为 了 简化 说 明 ， 这 里 只 设置 了 5 秒 、10 秒 、30 秒 、1 分 钟 这 四 个 等 级 。 根 据 
应 用 需求 的 不 同 ， 生 产 者 在 发 送 消息 的 时 候 通过 设置 不 同 的 路 由 键 ， 以 此 将 消息 发 送 到 与 交换 
器 绑 定 的 不 同 的 队列 中 。 这 里 队列 分 别 设置 了 过 期 时 间 为 5 秒 、10 秒 、30 秒 、1 分 钟 ， 同 时 也 
分 别 配置 了 DLX 和 相应 的 死 信 队 列 。 当 相应 的 消息 过 期 时 ， 就 会 转 存 到 相应 的 死 信 队 列 〈 即 延 
迟 队 列 ) 中 ， 这 样 消费 者 根据 业务 自身 的 情况 ， 分 别 选择 不 同 延 迟 等 级 的 延迟 队列 进行 消费 。 


为 每 个 队列 设置 一 
为 每 个 队列 设置 不 
同 的 过 期 时 间 B 7 vo 


queue delay 5s 









queue, delay 10s 


queue, delay 30s 
| 


type="direct” 


queue delay 1min 


图 4-5 延迟 队列 
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4.5 ”优先 级 队列 


优先 级 队列 ， 顾 名 思 义 ， 具 有 高 优先 级 的 队列 具有 高 的 优先 权 ， 优 先 级 高 的 消息 具备 优先 
被 消费 的 特权 。 


可 以 通过 设置 队列 的 x-max-priority 参数 来 实现 。 示 例 代码 如 代码 清单 4.9 所 示 。 





Map«String, Object» args = new HashMap«String, Object»(); 
args.put("x-max-priority", 10); 
channel.queueDeclare("queue.priority", true, false, false, args); 


通过 Web 管理 页 面 可 以 看 到 “Pri” 的 标识 ， 如 图 4-6 所 示 。 



















图 4-6 ”优先 级 队列 的 属性 展示 
上 面 的 代码 演示 的 是 如 何 配置 一 个 队列 的 最 大 优先 级 。 在 此 之 后 ， 需 要 在 发 送 时 在 消息 中 
设置 消息 当前 的 优先 级 。 示 例 代 码 如 代码 清单 4-10 所 示 。 





Toig 





AMQP.BasicProperties.Builder builder = new AMQP.BasicProperties.Builder(); 

builder.priority(5); 

AMQP.BasicProperties properties = builder.build(); 

channel.basicPublish("exchange priority","rk priority",properties, ("messages 
").getBytes()); 


上 面 的 代码 中 设置 消息 的 优先 级 为 5。 默 认 最 低 为 0， 最 高 为 队列 设置 的 最 大 优先 级 。 优 先 
级 高 的 消息 可 以 被 优先 消费 ， 这 个 也 是 有 前 提 的 : 如 果 在 消费 者 的 消费 速度 大 于 生产 者 的 速度 
H Broker 中 没有 消息 堆积 的 情况 下 ， 对 发 送 的 消息 设置 优先 级 也 就 没有 什么 实际 意义 。 因 为 生 
产 者 刚 发 送 完 一 条 消息 就 被 消费 者 消费 了 ， 那 么 就 相当 于 Broker 中 至 多 只 有 一 条 消息 ， 对 于 单 
条 消息 来 说 优先 级 是 没有 什么 意义 的 。 
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4.6 RPC 实现 


RPC， 是 Remote Procedure Call 的 简称 ， 即 远程 过 程 调 用 。 它 是 一 种 通过 网 络 从 远程 计算 
机 上 请 求 服务 ， 而 不 需要 了 解 底层 网 络 的 技术 。RPC 的 主要 功用 是 让 构建 分 布 式 计 算 更 容易 ， 
在 提供 强大 的 远程 调用 能 力 时 不 损失 本 地 调用 的 语义 简洁 性 。 


通俗 点 来 说 , 假设 有 两 台 服 务 器 A 和 B， 一 个 应 用 部 署 在 A 服务 器 上 ， 想 要 调用 B 服务 器 
上 应 用 提供 的 函数 或 者 方法 ， 由 于 不 在 同一 个 内 存 空间 ， 不 能 直接 调用 ， 需 要 通过 网 络 来 表达 
调用 的 语义 和 传达 调用 的 数据 。 

RPC 的 协议 有 很 多 ， 比 如 最 早 的 CORBA、Java RMI、WebService 的 RPC 风格 、Hessian、 
Thrift 甚至 还 有 Restful API。 

一 般 在 RabbitMQ 中 进行 RPC 是 很 简单 。 客 户 端 发 送 请 求 消息 ， 服 务 端 回复 响应 的 消息 。 
为 了 接收 响应 的 消息 , 我 们 需要 在 请 求 消息 中 发 送 一 个 回调 队列 (参考 下 面 代码 中 的 replyTo)。 
可 以 使 用 默认 的 队列 ， 具 体 示例 代码 如 代码 清单 4-11 所 示 。 





String callbackQueueName = channel.queueDeclare() .getQueue (); 
BasicProperties props = new 

BasicProperties.Builder().replyTo (callbackQueueName).build(); 
channel.basicPublish("", "rpc queue",props,message.getBytes()); 
// then code to read a response message from the callback queue... 


对 于 代码 中 涉及 的 BasicProperties 这 个 类 , 在 3.3 节 中 我 们 在 阐述 发 送 消息 的 时 候 讲 
解 过 ， 其 包含 14 个 属性 ， 这 里 就 用 到 两 个 属性 。 


信 replyTo: 通常 用 来 设置 一 个 回调 队列 。 
+ correlationId: 用 来 关联 请 求 (request) 和 其 调用 RPC 之 后 的 回复 (response)。 


如 果 像 上 面 的 代码 中 一 样 ， 为 每 个 RPC 请 求 创建 一 个 回调 队列 ， 则 是 非常 低 效 的 。 但 是 幸 
运 的 是 这 里 有 一 个 通用 的 解决 方案 一 一 可 以 为 每 个 客户 端 创建 一 个 单一 的 回调 队列 。 


这 样 就 产生 了 一 个 新 的 问题 ， 对 于 回调 队列 而 言 ， 在 其 接收 到 一 条 回复 的 消息 之 后 ， 它 并 
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不 知道 这 条 消息 应 该 和 哪 一 个 请 求 匹配 。 这 里 就 用 到 correlationId 这 个 属性 了 ， 我 们 应 该 
为 每 一 个 请 求 设置 一 个 唯一 的 correlationId。 之 后 在 回调 队列 接收 到 回复 的 消息 时 ， 可 以 
根据 这 个 属性 匹配 到 相应 的 请 求 ,如 果 回 调 队 列 接收 到 一 条 未 知 correlationId 的 回复 消息 ， 
可 以 简单 地 将 其 丢弃 。 


你 有 可 能 会 问 ， 为 什么 要 将 回调 队列 中 的 位 置 消息 丢弃 而 不 是 仅仅 将 其 看 作 失 败 ? 这 样 可 
以 针对 这 个 失败 做 一 些 弥 补 措施 。 参 考 图 4-7， 考 虑 这 样 一 种 情况 ，RPC 服务 器 可 能 在 发 送 给 
回调 队列 (amq.gen-LhQzlgv3GhDOv8PIDabOXA) 并 且 在 确认 接收 到 请 求 的 消息 (rpc_queue 
中 的 消息 ) 之 后 挂 掉 了 ， 那 么 只 需 重 启 下 RPC 服务 器 即 可 ，RPC 服务 会 重新 消费 rpe queue 队 
列 中 的 请 求 ， 这 样 就 不 会 出 现 RPC 服务 端 未 处 理 请 求 的 情况 。 这 里 的 回调 队列 可 能 会 收 到 重复 
消息 的 情况 ， 这 需要 客户 端 能 够 优雅 地 处 理 这 种 情况 ， 并且 RPC 请 求 也 需要 保证 其 本 身 是 窜 等 
的 (补充 : 根据 3.5 节 的 介绍 ， 消 费 者 消费 消息 一 般 是 先 处 理 业务 逻辑 ， 再 使 用 Basic.Ack 
确认 已 接收 到 消息 以 防止 消息 不 必要 地 丢失 )。 





图 4-7 RPC 示意 图 
根据 图 4-7 所 示 ，RPC 的 处 理 流程 如 下 : 


d) 当 客 户 端 启动 时 ， 创 建 一 个 匿名 的 回调 队列 (名 称 由 RabbitMQ 自动 创建 ， 图 4-7 中 
的 回调 队列 为 amq.gen-LhQzlgv3GhDOv8PIDabOXA)。 


(2) 客户 端 为 RPC 请 求 设置 2 个 属性 : replyTo 用 来 告知 RPC 服务 端 回 复 请 求 时 的 目的 
队列 ， 即 回调 队列 ;correlationId 用 来 标记 一 个 请 求 。 


G) 请 求 被 发 送 到 rpc_queue 队列 中 。 


(4) RPC 服务 端 监听 rpc queue 队列 中 的 请 求 ， 当 请 求 到 来 时 ， 服 务 端 会 处 理 并 且 把 带 有 
结果 的 消息 发 送 给 客户 端 。 接 收 的 队列 就 是 replyTo 设 定 的 回调 队列 。 
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(5) 客户 端 监 听 回 调 队 列 ， 当 有 消息 时 ， 检 查 correlationId 属性 ， 如 果 与 请 求 匹配 ， 
那 就 是 结果 了 。 


下 面 沿 用 RabbitMQ 官方 网 站 的 一 个 例子 来 做 说 明 ,RPC 客户 端 通过 RPC 来 调用 服务 端的 
方法 以 便 得 到 相应 的 斐 波 那 契 值 。 


首先 是 服务 端的 关键 代码 ， 代 码 清单 4-12 所 示 。 





public class RPCServer { 
private static final String RPC QUEUE NAME - "rpc queue"; 


public static void main(String args[]) throws Exception { 
// 省 略 了 创建 Connection 和 Channel 的 过 程 ， 具 体 可 以 参考 1.4.4 节 
channel.queueDeclare(RPC QUEUE NAME, false, false, false, null); 
channel.basicQos (1); 
System.out.println(" [x] Awaiting RPC requests"); 


Consumer consumer = new DefaultConsumer (channel) ( 
QGOverride 
public void handleDelivery(String consumerTag, 
Envelope envelope, 
AMOP.BasicProperties properties, 
byte[] body) throws IOException { 
AMQP.BasicProperties replyProps = new AMQP.BasicProperties 


.Builder() 
.correlationId(properties.getCorrelationId()) 
.build(); 

String response = ""; 


try ( 
String message - new String(body, "UTF-8"); 
int n = Integer.parseInt (message); 
System.out.println(" [.] fib(" + message + ")"); 
response += fib(n); 

) catch (RuntimeException e) ( 
System.out.println(" [.] " * e.toString()); 

) finally ( 
channel.basicPublish("", properties.getReplyTo(), 

replyProps, response.getBytes ("UTF-8")); 

channel.basicAck(envelope.getDeliveryTag(), false); 


}; 
channel.basicConsume (RPC QUEUE NAME, false, consumer); 
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private static int fib(int n)( 
if (n == 0) return 0; 
if (n == 1) return 1; 
return fib(n - 1) + fib(n - 2); 


) 
RPC 客户 端的 关键 代码 


Imi 


T 
APAI 






Tu 


如 代码 清单 4-13 所 示 。 









public class RPCClient ( 
private Connection connection; 
private Channel channel; 
private String requestQueueName - "rpc queue"; 
private String replyQueueName; 
private QueueingConsumer consumer; 


public RPCClient() throws IOException, TimeoutException ( 
// 省 略 了 创建 Connection M Channel 的 过 程 ， 具 体 可 以 参考 1.4.4 节 
replyQueueName = channel.queueDeclare().getQueue(); 
consumer - new QueueingConsumer (channel); 
channel.basicConsume (replyQueueName, true,consumer); 


public String call(String message) throws IOException, 
ShutdownSignalException, ConsumerCancelledException, 
InterruptedException ( 
String response - null; 
String corrId = UUID.randomUUID().toString(); 


BasicProperties props - new BasicProperties.Builder() 
.correlationId(corrId) 
.replyTo (replyQueueName) 
.build(); 

channel.basicPublish("", requestQueueName, props, message.getBytes()); 


while (true) { 
QueueingConsumer.Delivery delivery = consumer.nextDelivery(); 
if(delivery.getProperties().getCorrelationId().equals(corrId))( 
response = new String (delivery.getBody()); 
break; 
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return response; 


} 


public void close() throws Exception{ 
connection.close(); 


} 


public static void main (String args[]) throws Exception{ 
RPCClient fibRpc = new RPCClient(); 
System.out.println(" [x] Requesting fib(30)"); 
String response = fibRpc.call("30"); 
System.out.println(" [.] Got '"«response-*"'"); 
fibRpc.close(); 


4.7 ”持久 化 


“持久 化 ”这 个 词汇 在 前 面 的 篇 幅 中 有 多 次 提 及 ， 持 久 化 可 以 提高 RabbitMQ 的 可 靠 性 ， 以 
防 在 异常 情况 (重启 、 关 闭 、 宕 机 等 ) 下 的 数据 丢失 。 本 节 针 对 这 个 概念 做 一 个 总 结 。RabbitMQ 
的 持久 化 分 为 三 个 部 分 : 交换 器 的 持久 化 、 队 列 的 持久 化 和 消息 的 持久 化 。 


交换 器 的 持久 化 是 通过 在 声明 队列 是 将 durable 参数 置 为 true 实现 的 ,详细 可 以 参考 3.2.1 
节 。 如 果 交 换 器 不 设置 持久 化 , 那么 在 RabbitMQ 服务 重启 之 后 , 相关 的 交换 器 元 数据 会 丢失 ， 
不 过 消息 不 会 丢失 ， 只 是 不 能 将 消息 发 送 到 这 个 交换 器 中 了 。 对 一 个 长 期 使 用 的 交换 器 来 说 ， 
建议 将 其 置 为 持久 化 的 。 


队列 的 持久 化 是 通过 在 声明 队列 时 将 durable 参数 置 为 true 实现 的 ， 详 细 内 容 可 以 参考 
3.2.2 节 。 如 果 队 列 不 设置 持久 化 , 那么 在 RabbitMQ 服务 重启 之 后 , 相关 队列 的 元 数据 会 丢失 ， 
此 时 数据 也 会 丢失 。 正 所 谓 “ 皮 之 不 存 ， 毛 将 看 附 ”队列 都 没有 了 ， 消 息 又 能 存在 哪里 呢 ? 

队列 的 持久 化 能 保证 其 本 身 的 元 数据 不 会 因 异 常情 况 而 丢失 , 但 是 并 不 能 保证 内 部 所 存储 的 
消息 不 会 丢失 。 要 确保 消息 不 会 丢失 ， 需 要 将 其 设置 为 持久 化 。 通 过 将 消息 的 投递 模式 
(BasicProperties 中 的 deliveryMode 属性 ) 设置 为 2 即 可 实现 消息 的 持久 化 。 前 面 示例 
中 多 次 提 及 的 MessageProperties.PERSISTENT TEXT PLAIN 实际 上 是 封装 了 这 个 属性 : 
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public static final BasicProperties PERSISTENT TEXT PLAIN - 
new BasicProperties ("text/plain", 
null, 
null, 
2,//deliveryMode 
0, null, nuli, mull, 
null, null, null, null; 
null, null); 


更 多 发 送 消息 的 详细 内 容 可 以 参考 3.3 节 。 


设置 了 队列 和 消息 的 持久 化 ， 当 RabbitMQ 服务 重启 之 后 ， 消 息 依旧 存在 。 单 单 只 设置 队 
列 持 久 化 ， 重 启 之 后 消息 会 丢失 ;单单 只 设置 消息 的 持久 化 ， 重 启 之 后 队列 消失 ， 继 而 消息 也 
丢失 。 单 单 设置 消息 持久 化 而 不 设置 队列 的 持久 化 显得 毫 无 意义 。 


注意 要 点 : 


可 以 将 所 有 的 消息 都 设置 为 持久 化 ， 但 是 这 样 会 严重 影响 RabbitMQ 的 性 能 (随机 )。 写 入 
磁盘 的 速度 比 写 入 内 存 的 速度 慢 得 不 只 一 点 点 。 对 于 可 靠 性 不 是 那么 高 的 消息 可 以 不 采用 持久 
化 处 理 以 提高 整体 的 吞吐 量 。 在 选择 是 否 要 将 消息 持久 化 时 ， 需 要 在 可 靠 性 和 吐 吞 量 之 间 做 一 
个 权衡 ， 


将 交换 器 、 队 列 、 消 息 都 设置 了 持久 化 之 后 就 能 百分之百 保证 数据 不 丢失 了 吗 ? 答案 是 否 
定 的 。 


首先 从 消费 者 来 说 ,如 果 在 订阅 消费 队列 时 将 autoAck 参数 设置 为 true, 那么 当 消 费 者 接 
收 到 相关 消息 之 后 ， 还 没 来 得 及 处 理 就 宕 机 了， 这 样 也 算数 据 丢 失 。 这 种 情况 很 好 解决 ， 将 
autoAck 参数 设置 为 false， 并 进行 手动 确认 ， 详 细 可 以 参考 3.5 节 。 


其 次 ， 在 持久 化 的 消息 正确 存 入 RabbitMQ 之 后 ， 还 需要 有 一 段 时 间 (虽然 很 短 ， 但 是 不 
可 忽视 ) 才能 存 入 磁盘 之 中 。RabbitMQ 并 不 会 为 每 条 消息 都 进行 同步 存盘 (调用 内 核 的 fsync' 
方法 ) 的 处 理 ， 可 能 仅仅 保存 到 操作 系统 缓存 之 中 而 不 是 物理 磁盘 之 中 。 如 果 在 这 段 时 间 内 
RabbitMQ 服务 节点 发 生 了 宕 机 、 重 启 等 异常 情况 ， 消 息 保存 还 没 来 得 及 落 盘 ,那么 这 些 消息 将 


| fsync 在 Linux 中 的 意义 在 于 同步 数据 到 存储 设备 上 。 大 多 数 块 设备 的 数据 都 是 通过 缓存 进行 的 ， 将 数据 写 到 文件 上 通常 将 该 
数据 由 内 核 复制 到 缓存 中 ， 如 果 缓 存 尚未 写 满 ， 则 不 将 其 排 入 输出 队列 上 ， 而 是 等 待 其 写 满 或 者 当 内 核 需要 重用 该 缓存 时 ， 再 
将 该 缓存 排 入 输出 队列 ， 进 而 同步 到 设备 上 。 这 种 策略 的 好 处 是 减少 了 磁盘 读 写 次 数 ， 不 足 的 地 方 是 降低 了 文件 内 容 的 更 新 速 
度 ， 使 其 不 能 时 刻 同 步 到 存储 设备 上 ， 当 系统 发 生 故 障 时 ， 这 种 机 制 很 有 可 能 导致 了 文件 内 容 的 丢失 。 因 此 ， 内 核 提供 了 fsync 
接口 ， 用 户 可 以 根据 自己 的 需要 通过 此 接口 更 新 数据 到 存储 设备 上 。 
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ZER. 


这 个 问题 怎么 解决 呢 ? 这 里 可 以 引入 RabbitMQ 的 镜像 队列 机 制 〈 详 细 参 考 9.4 节 )， 相 当 
于 配置 了 副本 ， 如 果 主 节点 (master) 在 此 特殊 时 间 内 挂 掉 ， 可 以 自动 切换 到 从 节点 〈slave)， 
这 样 有 效 地 保证 了 高 可 用 性 ， 除 非 整个 集群 都 挂 挤 。 虽 然 这 样 也 不 能 完全 保证 RabbitMQ 消息 
不 丢失 ， 但 是 配置 了 镜像 队列 要 比 没有 配置 镜像 队列 的 可 靠 性 要 高 很 多 ， 在 实际 生产 环境 中 的 
关键 业务 队列 一 般 都 会 设置 镜像 队列 。 


还 可 以 在 发 送 端 引 入 事务 机 制 或 者 发 送 方 确 认 机 制 来 保证 消息 已 经 正确 地 发 送 并 存储 至 
RabbitMQ 中 ， 前 提 还 要 保证 在 调用 channel.basicPublish 方法 的 时 候 交 换 器 能 够 将 消息 
正确 路 由 到 相应 的 队列 之 中 。 详 细 可 以 参考 下 一 节 。 


4.8 生产 者 确认 


在 使 用 RabbitMQ 的 时 候 ， 可 以 通过 消息 持久 化 操作 来 解决 因为 服务 器 的 异常 崩溃 而 导致 
的 消息 丢失 ， 除 此 之 外 ， 我 们 还 会 遇 到 一 个 问题 ， 当 消息 的 生产 者 将 消息 发 送出 去 之 后 ， 消 息 
到 底 有 没有 正确 地 到 达 服 务 器 呢 ? 如 果 不 进行 特殊 配置 ， 默 认 情 况 下 发 送 消息 的 操作 是 不 会 返 
回 任何 信息 给 生产 者 的 ， 也 就 是 默认 情况 下 生产 者 是 不 知道 消息 有 没有 正确 地 到 达 服 务 器 。 如 
果 在 消息 到 达 服 务 器 之 前 已 经 丢失 ， 持 久 化 操作 也 解决 不 了 这 个 问题 ， 因 为 消息 根本 没有 到 达 
服务 器 ， 何 谈 持久 化 ? 


RabbitMQ 针对 这 个 问题 ， 提 供 了 两 种 解决 方式 : 
€ 通过 事务 机 制 实现 ; 
$ 通过 发 送 方 确 认 (publisher confirm) 机 制 实现 。 


4.8.1 事务 机 制 — 


RabbitMQ 客户 端 中 与 事务 机 制 相 关 的 方法 有 三 个 : channel.txSelect , 
channel.txCommit 和 channel.txRollback. channel.txSelect 用 于 将 当前 的 信道 
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设置 成 事务 模式 ，channel .txCommit 用 于 提交 事务 ，channel .txRollback 用 于 事务 回 
滚 。 在 通过 channel.txSelect 方法 开启 事务 之 后 ， 我 们 便 可 以 发 布 消息 给 RabbitMQ T, 
如 果 事务 提交 成 功 ， 则 消息 一 定 到 达 了 RabbitMQ 中 ， 如 果 在 事务 提交 执行 之 前 由 于 RabbitMQ 
异常 月 溃 或 者 其 他 原因 抛 出 异常 ， 这 个 时 候 我 们 便 可 以 将 其 捕获 ， 进 而 通过 执行 
channel.txRollback 方法 来 实现 事务 回 滚 。 注 意 这 里 的 RabbitMQ 中 的 事务 机 制 与 大 多 数 
数据 库 中 的 事务 概念 并 不 相同 ， 需 要 注意 区 分 。 


关键 示例 代码 如 代码 清单 4-14 所 示 。 























channel.txSelect(); 

channel.basicPublish (EXCHANGE NAME,ROUTING KEY, 
MessageProperties.PERSISTENT TEXT PLAIN, 
"transaction messages".getBytes()); 

channel.txCommit(); 


上 面 代码 对 应 的 AMQP 协议 流转 过 程 如 图 4-8 所 示 。 


pi a 
Tx.Commit-Ok ! 


wert mem ema 


此 处 省 略 connection 和 channel 的 关闭 . 


4-8 AMQP 协议 流转 过 程 
可 以 发 现 开启 事务 机 制 与 不 开启 (参考 图 2-10) 相 比 多 了 四 个 步 又: 
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9 客户 端 发 送 rx .Select， 将 信道 置 为 事务 模式 ; 

* Broker 回复 Tx.Select-Ok， 确 认 已 将 信道 置 为 事务 模式 ; 
9 在 发 送 完 消息 之 后 ， 客 户 端 发 送 Tx .Commit 提交 事务 ; 

分 Broker 回复 Tx.Commit-Ok， 确 认 事 务 提交 。 


上 面 所 陈述 的 是 正常 的 情况 下 的 事务 机 制 运转 过 程 ， 而 事务 回 滚 是 什么 样子 呢 ? 我们 先 来 
参考 下 面 一 段 示 例 代 码 〈 代 码 清单 4-15)， 来 看 看 怎么 使 用 事务 回 滚 。 





try i 
channel.txSelect(); 
channel.basicPublish(exchange, routingKey, 
MessageProperties.PERSISTENT TEXT PLAIN, msg.getBytes()); 
int result = 1 / 0; 
channel.txCommit(); 
) catch (Exception e) { 
e.printStackTrace(); 
channel.txRollback(); 
} 


上 面 代码 中 很 明显 有 一 个 java.lang.ArithmeticException， 在 事务 提交 之 前 捕获 
到 异常 ， 之 后 显 式 地 提交 事务 回 滚 ， 其 AMQP 协议 流转 过 程 如 图 4-9 所 示 。 


~------n-q----------------------------------------------on-oni---------， 


Basic.Publish ------- -mv Ver » í 


| TkRollbck = 
i — 
n TxRollback-Ok! 


此 处 省 略 Connection 和 channel 的 关闭 


图 4-9 AMQP 协议 流转 过 程 
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如 果 要 发 送 多 条 消息 , 则 将 channel.basicPublish 和 channelL.txCommit 等 方法 包 


—Ó 


里 进 循环 内 即 可 ， 可 以 参考 如 下 示例 代码 ，( 代 码 清单 4-160. 





代码 清单 4- 


channel.txSelect(); 
for(int i-0;i«LOOP TIMES;i++) ( 

try ( 

channel.basicPublish("exchange", "routingKey", null, 
("messages" + i).getBytes()); 

channel.txCommit (); 

) catch (IOException e) ( 
e.printStackTrace(); 
channel.txRollback(); 


) 

事务 确实 能 够 解决 消息 发 送 方 和 RabbitMQ 之 间 消 息 确认 的 问题 ， 只 有 消息 成 功 被 
RabbitMQ 接收 ,事务 才能 提交 成 功 ,否则 便 可 在 捕获 异常 之 后 进行 事务 回 深 , 与 此 同时 可 以 进 
行 消息 重 发 。 但 是 使 用 事务 机 制 会 “ 吸 干 ”RabbitMQ 的 性 能 ， 那 么 有 没有 更 好 的 方法 既 能 保证 
消息 发 送 方 确认 消息 已 经 正确 送 达 , 又 能 基本 上 不 带 来 性 能 上 的 损失 呢 ? 从 AMQP 协议 层面 来 
看 并 没有 更 好 的 办 法 ， 但 是 RabbitMQ 提供 了 一 个 改进 方案 ， 即 发 送 方 确认 机 制 ,详情 请 看 下 一 
节 的 介绍 。 


4.8.2 ”发 送 方 确认 机 制 


前 面 介绍 了 RabbitMQ 可 能 会 遇 到 的 一 个 问题 ， 即 消息 发 送 方 〈 生 产 者 ) 并 不 知道 消息 是 
否 真正 地 到 达 了 RabbitMQ。 随 后 了 解 到 在 AMQP 协议 层面 提供 了 事务 机 制 来 解决 这 个 问题 ， 
但 是 采用 事务 机 制 实现 会 严重 降低 RabbitMQ 的 消息 吞吐 量 ， 这 里 就 引入 了 一 种 轻 量 级 的 方式 
一 一 发 送 方 确 认 Cpublisher confirm) 机制。 


生产 者 将 信道 设置 成 confirm HA) 模式 ， 一 旦 信道 进入 confirm 模式 ， 所 有 在 该 信道 上 
面 发 布 的 消息 都 会 被 指派 一 个 唯一 的 ID (从 1 开始 ), 一 旦 消息 被 投递 到 所 有 匹配 的 队列 之 后 ， 
RabbitMQ 就 会 发 送 一 个 确认 (Basic.Ack) 给 生产 者 (包含 消息 的 唯一 ID)， 这 就 使 得 生产 
者 知晓 消息 已 经 正确 到 达 了 目的 地 了 。 如 果 消 息 和 队列 是 可 持久 化 的 ， 那 么 确认 消息 会 在 消息 
写 入 磁盘 之 后 发 出 。RabbitMQ 回 传 给 生产 者 的 确认 消息 中 的 deliveryTag 包含 了 确认 消息 
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的 序号 ， 此 外 RabbitMQ 也 可 以 设置 channel .basicAck 方法 中 的 multiple 参数 ， 表 示 到 
这 个 序号 之 前 的 所 有 消息 都 已 经 得 到 了 处 理 ， 可 以 参考 图 4-10。 注 意 辨别 这 里 的 确认 和 消费 时 
候 的 确认 之 间 的 异同 。 





~ Basic.Ack 
{deliveryTag=1, mutilpie-false) 


4-10 ”发 送 方 确认 机 制 


事务 机 制 在 一 条 消息 发 送 之 后 会 使 发 送 端 阻塞 ， 以 等 待 RabbitMQ 的 回应 ， 之 后 才能 继续 
发 送 下 一 条 消息 。 相 比 之 下 , 发 送 方 确认 机 制 最 大 的 好 处 在 于 它 是 异步 的 , 一 旦 发 布 一 条 消息 ， 
生产 者 应 用 程序 就 可 以 在 等 信道 返回 确认 的 同时 继续 发 送 下 一 条 消息 ， 当 消息 最 终 得 到 确认 之 
后 ， 生 产 者 应 用 程序 便 可 以 通过 回调 方法 来 处 理 该 确认 消息 ， 如 果 RabbitMQ 因为 自身 内 部 错 
误导 致 消息 丢失 ， 就 会 发 送 一 条 nack (Basic.Nack) 命令 ， 生 产 者 应 用 程序 同样 可 以 在 回调 
方法 中 处 理 该 nack 命令 。 


生产 者 通过 调用 channel.confirmSelect 方法 (Hl Confirm.Select 命令 ) 将 信道 
设置 为 confirm 模式 ， 之 后 RabbitMQ 会 返回 Confirm.Select-Ok 命令 表示 同意 生产 者 将 当 
前 信道 设置 为 confirm 模式 。 所 有 被 发 送 的 后 续 消息 都 被 ack 或 者 nack 一 次 ， 不 会 出 现 一 条 消 
息 既 被 ack 又 被 nack 的 情况 ， 并 且 RabbitMQ 也 并 没有 对 消息 被 confirm 的 快慢 做 任何 保证 。 


下 面 看 一 下 publisher confirm 机 制 怎么 运作 ， 简 要 代码 如 代码 清单 4-17 所 示 。 





try { 
channel.confirmSelect ();// 将 信道 置 为 publisher confirm 模式 
// 之 后 正常 发 送 消息 
channel.basicPublish("exchange", "routingKey", null, 


"publisher confirm test".getBytes()); 
if (!channel.waitForConfirms()) { 
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System.out.println("send message failed"); 
// do something else.... 
) 
) catch (InterruptedException e) ( 
e.printStackTrace(); 
) 


如 果 发 送 多 条 消息 ， 只 需要 将 channel.basicPublish 和 channel.waitFor 
Confirms 方法 包 庄 在 循环 里 面 即 可 ， 可 以 参考 事务 机 制 ， 不 过 不 需要 把 
channel.confirmSelect 方法 包 庄 在 循环 内 部 。 


在 publisher confirm 模式 下 发 送 多 条 消息 的 AMQP 协议 流转 过 程 可 以 参考 图 4-11. 


ONE: IE MM -——P— ——— E A A N E NIE 
l 此 处 省 略 Connection 和 channel 的 开启 . : 
: ConfirmSelect ~ i 
| mm ey yn » ' 
NEM Confirm.Select-Ok ! 
i i 
: Basic.Publish =: » i 
: 三- Basic.Ack | 
| BsiPulileh Ssnin ———AÀ 
: P € —— E Basic.Ack | 
! Badcbih emm — > | 
———— ———— OC Basic.Ack | 
: 此 处 省 赔 connection 和 channel 的 关闭 : 


4-11 发送 多 条 消息 的 AMQP 协议 流转 过 程 
对 于 channel.waitForConfirms 而 言 ， 在 RabbitMQ 客户 端 中 它 有 4 个 同类 的 方法 : 


(1) boolean waitForConfirms() throws InterruptedException; 
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(2) boolean waitForConfirms (long timeout) throws InterruptedException, 


TimeoutException; 
(3) void waitForConfirmsOrDie() throws IOException, InterruptedException; 


(4) void waitForConfirmsOrDie(long timeout) throws IOException, Interrupted 


Exception, TimeoutException; 


如 果 信 道 没 有 开启 publisher confirm 模式 ， 则 调用 任何 waitForConfirms 方法 都 会 报 出 
java.lang.IllegalStateException。 对 于 没有 参数 的 waitForConfirms 方法 来 说 ， 
其 返回 的 条 件 是 客户 端 收 到 了 相应 的 Basic.Ack/ .Nack 或 者 被 中 断 。 参 数 timeout 表示 超 
时 时 间 ， 一 旦 等 待 RabbitMQ 回应 超时 就 会 抛 出 java.util.concurrent. 
TimeoutException 的 异常 。 两 个 waitForConfirmsOrDie 方法 在 接收 到 RabbitMQ 返回 
的 Basic.Nack 之 后 会 抛 出 java.io.IOException。 业 务 代码 可 以 根据 自身 的 特性 灵活 地 
运用 这 四 种 方法 来 保障 消息 的 可 靠 发 送 。 

前 面 提 到 过 RabbitMQ 引入 了 publisher confirm 机 制 来 弥补 事务 机 制 的 缺陷 , 提高 了 整体 的 
吞吐 量 ， 那 么 我 们 来 对 比 下 两 者 之 间 的 QPS， 测 试 代码 可 以 参考 上 面 的 示例 代码 。 


测试 环境 客户 端 和 Broker 机 器 配置 一 一 CPU 为 24 核 、 主 频 为 2600Hz、 内 存 为 64GB、 
硬盘 为 1TB。 客 户 端 发 送 的 消息 体 大 小 为 10B， 单 线程 发 送 ， 并 且 消 息 都 进行 持久 化 处 理 。 


测试 结果 如 图 4-12 所 示 。 


2500 一 























0 - l——————————— 
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图 4-12 事务 机 制 与 发 送 方 确认 机 制 的 QPS 对 比 
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4-12 中 的 横 坐 标 表 示 测 试 的 次 数 ， 纵 坐标 表示 QPS。 可 以 发 现 publisher confirm 与 事务 
机 制 相 比 ，QPS 并 没有 提高 多 少 ， 难 道 是 RabbitMQ 欺骗 了 我 们 ? 


我 们 再 来 回顾 下 前 面 的 示例 代码 ， 可 以 发 现 publisher confirm 模式 是 每 发 送 一 条 消息 后 就 
调用 channel.waitForConfirms 方法 , 之 后 等 待 服务 端的 确认 ， 这 实际 上 是 一 种 串 行 同步 
等 待 的 方式 。 事 务 机 制 和 它 一 样 ， 发 送 消 息 之 后 等 待 服务 端 确 认 ， 之 后 再 发 送 消息 。 两 者 的 存 
储 确认 原理 相同 , 尤其 对 于 持久 化 的 消息 来 说 , 两 者 都 需要 等 待 消息 确认 落 盘 之 后 才 会 返回 ( 调 
用 Linux 内 核 的 fsync 方法 )。 在 同步 等 待 的 方式 下 ，publisher confirm 机 制 发 送 一 条 消息 需要 通 
信 交 互 的 命令 是 2 条 :Basic.Publish 和 Basic.Ack; 事 务 机 制 是 3 条 :Basic.Publish、 
Tx.Commmit/.Commit-Ok (或 者 Tx.Rollback/ .Rollback-Ok)， 事 务 机制 多 了 一 个 命 
令 帧 报 文 的 交互 ， 所 以 QPS 会 略微 下 降 。 


注意 要 点 : 


(1 ) 事务 机 制 和 publisher confirm 机 制 两 者 是 互 斥 的 ， 不 能 共存 。 如 果 企 图 将 已 开启 事务 模式 
的 信道 再 设置 为 publisher confirm 模式 ，RabbitMQ 会 报错 : {amqp error, precondition 
failed, "cannot switch from tx to confirm mode", 'confirm.select'}; 或 
者 如 果 企 图 将 已 开启 publisher confirm 模式 的 信道 再 设置 为 事务 模式 ，RabbitMQ 也 会 报错 : 
(amqp error, precondition failed, "cannot switch from confirm to tx 


mode", 'tx.select' }. 


(2) 事务 机 制 和 publisher confirm 机 制 确保 的 是 消息 能 够 正确 地 发 送 至 RabbitMQ， 这 里 的 
“发 送 至 RabbitMQ” 的 含义 是 指 消息 被 正确 地 发 往 至 RabbitMQ 的 交换 器 ， 如 果 此 交换 器 没有 
匹配 的 队列 ， 那 么 消息 也 会 丢失 。 所 以 在 使 用 这 两 种 机 制 的 时 候 要 确保 所 涉及 的 交换 器 能 够 有 
匹配 的 队列 。 更 进一步 地 讲 ， 发 送 方 要 配合 mandatory 参数 或 者 备份 交换 器 一 起 使 用 来 提高 
消息 传输 的 可 靠 性 。 

publisher confirm 的 优势 在 于 并 不 一 定 需 要 同步 确认 。 这 里 我 们 改进 了 一 下 使 用 方式 ， 总结 
有 如 下 两 种 : 


信 批量 confirm 方法 : 每 发 送 一 批 消 息 后 , 调用 channel.waitForConfirms 方法 , 等 
待 服务 器 的 确认 返回 。 


信 异步 confirm 方法 : 提供 一 个 回调 方法 ， 服 务 端 确认 了 一 条 或 者 多 条 消息 后 客户 端 会 回 
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调 这 个 方法 进行 处 理 。 
在 批量 confirm 方法 中 ， 客 户 端 程序 需要 定期 或 者 定量 (达到 多 少 条 )， 亦 或 者 两 者 结合 
来 调用 channel.waitForConfirms 来 等 待 RabbitMQ 的 确认 返回 。 相 比 于 前 面 示例 中 的 普 
通 confirm 方法 ， 批 量 极 大 地 提升 了 confirm 的 效率 ， 但 是 问题 在 于 出 现 返回 Basic.Nack 或 
者 超时 情况 时 ， 客 户 端 需要 将 这 一 批 次 的 消息 全 部 重 发 ， 这 会 带 来 明显 的 重复 消息 数量 ， 并 且 
当 消 息 经 常 丢 失 时 ， 批 量 confirm 的 性 能 应 该 是 不 升 反 降 的 。 





try { 
channel.confirmSelect(); 
int MsgCount = 0; 
while (true) ( 
channel.basicPublish("exchange", "routingKey", 
null, "batch confirm test".getBytes()); 
// 将 发 送出 去 的 消息 存 入 缓存 中 ， 缓 存 可 以 是 
// 一 个 ArrayList 或 者 BlockingQueue 之 类 的 
if (++MsgCount >= BATCH COUNT) { 
MsgCount = 0; 
try { 
if (channel.waitForConfirms()) { 


// 将 缓存 中 的 消息 清空 
} 
// 将 缓存 中 的 消息 重新 发 送 


) catch (InterruptedException e) ( 
e.printStackTrace(); 


// 将 缓存 中 的 消息 重新 发 送 


) 
} 
} catch (IOException e) { 
e.printStackTrace(); 
} 


异步 confirm 方法 的 编程 实现 最 为 复杂 。 在 客户 端 Channel 接口 中 提供 的 
addConfirmListener 方法 可 以 添加 ConfirmListener 这 个 回调 接口 ， 这 个 
ConfirmListener 接口 包含 两 个 方法 : handleAck 和 handleNack， 分 别 用 来 处 理 
RabbitMQ 回 传 的 Basic.Ack 和 Basic.Nack。 在 这 两 个 方法 中 都 包含 有 一 个 参数 
deliveryTag (在 publisher confirm 模式 下 用 来 标记 消息 的 唯一 有 序 序号 )。 我 们 需要 为 每 一 
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个 信道 维护 一 个 “unconfirm” 的 消息 序号 集合 ， 每 发 送 一 条 消息 ， 集 合 中 的 元 素 加 1。 每 当 调 
用 ConfirmListener 中 的 handleAck 方法 时 ,“unconfirm ”集合 中 删 掉 相应 的 一 条 
(multiple 设置 为 false) 或 者 多 条 (multiple WAX true) 记录 。 从 程序 运行 效率 上 来 看 ， 
这 个 “unconfirm” 集 合 最 好 采用 有 序 集合 Sortedset 的 存储 结构 。 事 实 上 ，Java 客户 端 SDK 
中 的 waitForConfirms 方法 也 是 通过 Sortedset 维护 消息 序号 的 。 代 码 清单 4-19 为 我 们 





channel.confirmSelect(); 
channel.addConfirmListener (new ConfirmListener() ( 
public void handleAck(long deliveryTag, boolean multiple) 
throws IOException { 
System.out.println("Nack, SeqNo: " + deliveryTag 
于 ", multiple: " + multiple); 
if (multiple) ( 
confirmSet.headSet (deliveryTag - 1).clear(); 
) else ( 
confirmSet.remove (deliveryTag); 
} 
} 
public void handleNack (long deliveryTag, boolean multiple) 
throws IOException { 
if (multiple) { 
confirmSet.headSet(deliveryTag - 1).clear(); 
) else ( 
confirmSet.remove (deliveryTag); 


} 
// 注 意 这 里 需要 添加 处 理 消 息 重 发 的 场景 
) 
EN? 
// 下 面 是 演示 一 直 发 送 消 息 的 场景 
while (true) { 
long nextSeqNo = channel.getNextPublishSeqNo(); 
channel.basicPublish(ConfirmConfig.exchangeName, ConfirmConfig.routingKey, 
MessageProperties.PERSISTENT TEXT PLAIN, 
ConfirmConfig.msg 10B.getBytes()); 
confirmSet.add (nextSeqNo); 
) 


最 后 我 们 将 事务 、 普 通 confirm、 批 量 confirm 和 异步 confirm 这 4 种 方式 放 到 一 起 来 比较 
一 下 彼此 的 QPS。 测 试 环境 和 数据 和 图 4-12 中 的 测试 相同 ， 有 具体 测试 对 比如 图 4-13 所 示 。 
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4-13 4 种 方式 的 QPS 对 比 


可 以 看 到 批量 confirm 和 异步 confirm 这 两 种 方式 所 呈现 的 性 能 要 比 其余 两 种 好 得 多 。 事务 
机 制 和 普通 confirm 的 方式 吐 吞 量 很 低 ， 但 是 编程 方式 简单 ， 不 需要 在 客户 端 维护 状态 〈 这 里 
指 的 是 维护 aeliveryTag 及 缓存 未 确认 的 消息 )。 批 量 confirm 方式 的 问题 在 于 遇 到 RabbitMQ 
服务 端 返 回 Basic.Nack 需要 重 发 批量 消息 而 导致 的 性 能 降低 。 异 步 confirm 方式 编程 模型 最 
为 复杂 ， 而 且 和 批量 confirm 方式 一 样 需 要 在 客户 端 维护 状态 。 在 实际 生产 环境 中 采用 何 种 方 
式 ， 这 里 就 仁者 见 仁 智者 见 智 了 ， 不 过 强烈 建议 读者 使 用 异步 confirm 的 方式 。 


4.9 ”消费 端 要 点 介绍 


3.4 节 和 3.5 节 介 绍 了 如 何 正确 地 消费 消息 。 消 费 者 客户 端 可 以 通过 推 模式 或 者 拉 模式 的 方 
式 来 获取 并 消费 消息 ， 当 消费 者 处 理 完 业 务 逻 辑 需 要 手动 确认 消息 已 被 接收 ， 这 样 RabbitMQ 
才能 把 当前 消息 从 队列 中 标记 清除 ,当然 如 果 消 费 者 由 于 某 些 原因 无 法 处 理 当前 接收 到 的 消息 ， 
可 以 通过 channel .basicNack 或 者 channel.basicReject 来 拒绝 掉 。 


这 里 对 于 RabbitMQ 消费 端 来 说 ， 还 有 几 点 需要 注意 : 
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9 消息 分 发 ; 
分 消息 顺序 性 ; 


+ FM QueueingConsumer. 


4.9.1 消息 分 发 


当 RabbitMQ 队列 拥有 多 个 消费 者 时 ， 队 列 收 到 的 消息 将 以 轮 询 (round-robin) 的 分 发 方式 
发 送 给 消费 者 。 每 条 消息 只 会 发 送 给 订阅 列表 里 的 一 个 消费 者 。 这 种 方式 非常 适合 扩展 ， 而 且 
它 是 专门 为 并 发 程序 设计 的 。 如 果 现 在 负载 加 重 ， 那 么 只 需要 创建 更 多 的 消费 者 来 消费 处 理 消 
息 即 可 。 


很 多 时 候 轮 询 的 分 发 机 制 也 不 是 那么 优雅 .默认 情况 下 ,如 果 有 nn 个 消费 者 ,那么 RabbitMQ 
会 将 第 m 条 消息 分 发 给 第 m%n〔 取 余 的 方式 ) 个 消费 者 ，RabbitMQ 不 管 消费 者 是 否 消费 并 已 
经 确认 (Basic.Ack) 了 消息 。 试 想 一 下 ， 如 果 某 些 消费 者 任务 繁重 ， 来 不 及 消费 那么 多 的 消 
息 ， 而 某 些 其 他 消费 者 由 于 某 些 原因 《比如 业务 逻辑 简单 、 机 器 性 能 卓越 等 ) 很 快 地 处 理 完 了 
所 分 配 到 的 消息 ， 进 而 进程 空 有 了， 这 样 就 会 造成 整体 应 用 吞吐 量 的 下 降 。 


那么 该 如 何 处 理 这 种 情况 呢 ? 这 里 就 要 用 到 channel.basicQos (int prefetchCount) 
这 个 方法 ， 如 前 面 章节 所 述 ，channel .basicQos 方法 允许 限制 信道 上 的 消费 者 所 能 保持 的 最 大 
未 确认 消息 的 数量 。 

举例 说 明 ， 在 订阅 消费 队列 之 前 ， 消 费 端 程序 调用 了 channel .basicQos (5)， 之 后 订 
阅 了 某 个 队列 进行 消费 。RabbitMQ 会 保存 一 个 消费 者 的 列表 , 每 发 送 一 条 消息 都 会 为 对 应 的 消 
费 者 计数 ， 如 果 达 到 了 所 设 定 的 上 限 ， 那 么 RabbitMQ 就 不 会 向 这 个 消费 者 再 发 送 任何 消息 。 
直到 消费 者 确认 了 某 条 消息 之 后 , RabbitMQ 将 相应 的 计数 减 1, 之 后 消费 者 可 以 继续 接收 消息 ， 
直到 再 次 到 达 计 数 上 限 。 这 种 机 制 可 以 类 比 于 TCP/IP 中 的 “滑动 窗口 ”。 

注意 要 点 : 

Basic.Qos 的 使 用 对 于 拉 模 式 的 消费 方式 无 效 。 

channel.basicQos 有 三 种 类 型 的 重 载 方法 : 
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(1) void basicQos(int prefetchCount) throws IOException; 

(2) void basicQos(int prefetchCount, boolean global) throws IOException; 

(3) void basicQos(int prefetchSize, int prefetchCount, boolean global) throws 
IOException; 


前 面 介 绍 的 都 只 用 到 了 prefetchCount 这 个 参数 , 4 prefetchCount 设置 为 0 则 表示 
没有 上 限 。. 还 有 prefetchSize 这 个 参数 表示 消费 者 所 能 接收 未 确认 消息 的 总 体 大 小 的 上 限 ， 
单位 为 B， 设 置 为 0 则 表示 没有 上 限 。 


对 于 一 个 信道 来 说 ， 它 可 以 同时 消费 多 个 队列 ， 当 设置 了 prefetchCount 大 于 0 时 ， 这 个 
信道 需要 和 各 个 队列 协调 以 确保 发 送 的 消息 都 没有 超过 所 限定 的 prefetchCount 的 值 ， 这 样 会 
使 RabbitMQ 的 性 能 降低 ， 尤 其 是 这 些 队 列 分 散在 集群 中 的 多 个 Broker 节点 之 中 。RabbitMQ 为 了 
提升 相关 的 性 能 ， 在 AMQP 0-9-1 协议 之 上 重新 定义 了 global 这 个 参数 ， 对 比如 表 4-1 所 示 。 


表 4-1 global 参数 的 对 比 


global 参数 AMQP 0-9-1 RabbitMQ 


信道 上 所 有 的 消费 者 都 需要 遵从 prefetchCount 的 限 | 信道 上 新 的 消费 者 需要 遵从 prefetchCount 的 限定 什 
alse 
af 





当前 通信 链 路 〈Connection) 上 所 有 的 消费 者 都 需 | 信道 上 所 有 的 消费 者 都 需要 遵从 prefetchCount 的 限 
要 遵从 prefetchCount 的 限定 值 定 值 


前 面 章节 中 的 channel.basicQos 方法 的 示例 都 是 针对 单个 消费 者 的 ， 而 对 于 同一 人 
信道 上 的 多 个 消费 者 而 言 ， 如 果 设 置 了 prefetchCount 的 值 ， 那 么 都 会 生效 。 代 码 清单 
4-20 示例 中 有 两 个 消费 者 ， 各 自 的 能 接收 到 的 未 确认 消息 di 10。 


RE E Og 


Channel channel = ...; 

Consumer consumerl = ...; 

Consumer consumer2 = ...; 

channel.basicQos (10); / Per consumer limit 
channel.basicConsume ("my-queuel", false, consumerl); 
channel.basicConsume ("my-queue2", false, consumer2); 


iA dun 息 之 前 ， 既 设置 了 global 为 true 的 限制 ， 又 设置 了 global 为 false 的 限 
制 ， 那 么 哪个 会 生效 呢 ? RabbitMQ 会 确保 两 者 都 会 生效 。 举 例 说 明 ， 当 前 有 两 个 队列 queuel 
和 queue2: queuel 有 10 条 消息 ， 分 别 为 1 到 10; queue2 也 有 10 条 消息 ， 分 别 为 11 到 20。 有 
两 个 消费 者 分 别 消费 这 两 个 队列 ， 如 代码 清单 4-21 所 示 。 
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代码 清单 4-21 


Channel channel = . 
Consumer consumerl 
Consumer consumer2 
channel.basicQos (3, filas: // Per consumer limit 
channel.basicQos(5, true); // Per channel limit 

channel.basicConsume ("queuel", false, consumerl); 
channel.basicConsume ("queue2", false, consumer2); 


那么 这 里 每 个 消费 者 最 多 只 能 收 到 3 个 未 确认 的 消息 ， 两 个 消费 者 能 收 到 的 未 确认 的 消息 
个 数 之 和 的 上 限 为 5。 在 未 确认 消息 的 情况 下 ， 如 果 consumer! 接收 到 了 消息 1、2 和 3， 那么 
consumer? 至 多 只 能 收 到 11 和 12。 如 果 像 这 样 同 时 使 用 两 种 global 的 模式 , 则 会 增加 RabbitMQ 
的 负载 ， 因 为 RabbitMQ 需要 更 多 的 资源 来 协调 完成 这 些 限制 。 如 无 特殊 需要 ， 最 好 只 使 用 
global 为 false 的 设置 ， 这 也 是 默认 的 设置 。 





4.9.2 ”消息 顺序 性 


消息 的 顺序 性 是 指 消费 者 消费 到 的 消息 和 发 送 者 发 布 的 消息 的 顺序 是 一 致 的 。 举 个 例子 ， 
不 考虑 消息 重复 的 情况 ， 如 果 生 产 者 发 布 的 消息 分 别 为 msgl、msg2、msg3， 那 么 消费 者 必然 
也 是 按照 msgl. msg2. msg3 的 顺序 进行 消费 的 。 


目前 很 多 资料 显示 RabbitMQ 的 消息 能 够 保障 顺序 性 ， 这 是 不 正确 的 ， 或 者 说 这 个 观点 有 
很 大 的 局 限 性 。 在 不 使 用 任何 RabbitMQ 的 高 级 特性 ， 也 没有 消息 丢失 、 网 络 故障 之 类 异常 的 
情况 发 生 ， 并 且 只 有 一 个 消费 者 的 情况 下 ， 最 好 也 只 有 一 个 生产 者 的 情况 下 可 以 保证 消息 的 顺 
序 性 。 如 果 有 多 个 生产 者 同时 发 送 消息 ， 无 法 确定 消息 到 达 Broker 的 前 后 顺序 ， 也 就 无 法 验证 
消息 的 顺序 性 。 

那么 哪些 情况 下 RabbitMQ 的 消息 顺序 性 会 被 打破 呢 ? 下 面 介 绍 几 种 常见 的 情形 。 

如 果 生 产 者 使 用 了 事务 机 制 ， 在 发 送 消息 之 后 遇 到 异常 进行 了 事务 回 滚 ， 那 么 需要 重新 补 
偿 发 送 这 条 消息 ， 如 果 补 偿 发 送 是 在 另 一 个 线程 实现 的 ， 那 么 消息 在 生产 者 这 个 源头 就 出 现 了 
错 序 。 同 样 ， 如 果 启 用 publisher confirm 时 ， 在 发 生 超 时 、 中 断 ， 又 或 者 是 收 到 RabbitMQ 的 
Basic.Nack 命令 时 ， 那 么 同样 需要 补偿 发 送 ， 结 果 与 事务 机 制 一 样 会 错 序 。 或 者 这 种 说 法 有 
些 牵 强 ， 我 们 可 以 固执 地 认为 消息 的 顺序 性 保障 是 从 存 入 队列 之 后 开始 的 ， 而 不 是 在 发 送 的 时 
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候 开 始 的 。 


考虑 另 一 种 情形 , 如 果 生 产 者 发 送 的 消息 设置 了 不 同 的 超时 时 间 , 并 且 也 设置 了 死 信 队 列 ， 
整体 上 来 说 相当 于 一 个 延迟 队列 ， 那 么 消费 者 在 消费 这 个 延迟 队列 的 时 候 ， 消 息 的 顺序 必然 不 
会 和 生产 者 发 送 消息 的 顺序 一 致 。 


再 考虑 一 种 情形 , 如 果 消 息 设 置 了 优先 级 , 那么 消费 者 消费 到 的 消息 也 必然 不 是 顺序 性 的 。 


如 果 一 个 队列 按照 前 后 顺序 分 有 msgl. msg2. msg3. msg4 这 4 个 消息 , 同时 有 ConsumerA 
和 ConsumerB 这 两 个 消费 者 同时 订阅 了 这 个 队列 。 队 列 中 的 消息 轮 询 分 发 到 各 个 消费 者 之 中 ， 
ConsumerA 中 的 消息 为 msgl 和 msg3, ConsumerB 中 的 消息 为 msg2. msg4. ConsumerA 收 到 
消息 msgl 之 后 并 不 想 处 理 而 调用 了 Basic.Nack/ .Reject 将 消息 拒绝 ， 与 此 同时 将 
requeue 设置 为 tue， 这 样 这 条 消息 就 可 以 重新 存 入 队列 中 。 消 息 msgl 之 后 被 发 送 到 了 
ConsumerB 中 ， 此 时 ConsumerB 已 经 消费 了 msg2、msg4， 之 后 再 消费 msgl1， 这 样 消息 顺序 性 
也 就 错乱 了 。 或 者 消息 msgl 又 重新 发 往 ConsumerA 中 ， 此 时 ConsumerA 已 经 消费 了 msg3， 
那么 再 消费 msgl1， 消 息 顺序 性 也 无 法 得 到 保障 。 同 样 可 以 用 在 Basic.Recover 这 个 AMQP 
命令 中 。 


包括 但 不 仅 限 于 以 上 几 种 情形 会 使 RabbitMQ 消息 错 序 。 如 果 要 保证 消息 的 顺序 性 ， 需 要 
业务 方 使 用 RabbitMQ 之 后 做 进一步 的 处 理 , 比如 在 消息 体内 添加 全 局 有 序 标识 (类 似 Sequence 
ID) 来 实现 。 


4.9.3 弃 用 QueueingConsumer 


在 前 面 的 章节 中 所 介绍 的 订阅 消费 的 方式 都 是 通过 继承 DefaultConsumer 类 来 实现 的 。 
在 1.4.4 节 提 及 了 QueueingConsumer 这 个 类 ， 并 且 建 议 不 要 使 用 这 个 类 来 实现 订阅 消费 。 
QueueingConsumer 在 RabbitMQ 客户 端 3.x 版 本 中 用 得 如 火 如 茶 ， 但 是 在 4.x 版 本 开始 就 被 
标记 为 apeprecatedq， 想 必 这 个 类 中 有 些 无 法 弥补 的 缺陷 。 

不 妨 先 看 一 下 QueueingConsumer 的 用 法 ， 示 例 代 码 如 代码 清单 4-22 所 示 。 


-— 






— 





QueueingConsumer consumer - new QueueingConsumer (channel); 
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//channel.basicQos (64);// 使 用 QueueingConsumer 的 时 候 一 定 要 添加 ! 
channel.basicConsume (QUEUE NAME, false, "consumer zzh",consumer); 


while (true) { 
QueueingConsumer.Delivery delivery - consumer.nextDelivery(); 
String message - new String(delivery.getBody()); 
System.out.println(" [X] Received '" + message + "'"); 
channel.basicAck(delivery.getEnvelope().getDeliveryTag(),false); 
} 


乍 一 看 也 没什么 问题 ， 而 且 实际 生产 环境 中 如 果 不 是 太 “ 傲 娇 2 地 使 用 也 不 会 造成 什么 大 
IE. QueueingConsumer 本 身 有 几 个 大 缺陷 ， 需 要 读者 在 使 用 时 特别 注意 。 首 当 其 冲 的 就 
是 内 存 溢出 的 问题 ， 如 果 由 于 某 些 原 因 ， 队 列 之 中 堆积 了 比较 多 的 消息 ， 就 可 能 导致 消费 者 客 
户 端 内 存 滋 出 假死 ， 于 是 发 生 恶性 循环 ， 队 列 消息 不 断 堆积 而 得 不 到 消化 。 


采用 代码 清单 4-22 中 的 代码 进行 演示 ， 首 先 向 一 个 队列 发 送 200 多 MB 的 消息 ， 然 后 进行 
消费 。 在 客户 端 调用 channel.basicConsume 方法 订阅 队列 的 时 候 ，RabbitMQ 会 持续 地 将 
消息 发 往 QueueingConsumer 中 ,QueueingConsumer 内 部 使 用 LinkedBlockingQueue 
来 缓存 这 些 消 息 。 通 过 JVisualVM 可 以 看 到 堆 内 存 的 变化 ， 如 图 4-14 Bras. 
oth i run be i Cs Ee hg d coo 3 


大 小 : 353, 370, 112 个 字 节 已 使 用 : 256, 158, 656 个 字 节 
最 大 : 2, 111, 832, 064 个 字 节 


J00 a5 | 







| 
300 M81 | 








250 MB1 


200 MB1 | 








180 MB 







100 M8 






50 {4 
下 午 6: 20 下 午 6: 25 


ui 大 小 国 使 用 的 堆 






E 4-14 堆 内 存 的 变化 


由 图 4-14 可 以 看 到 堆 内 存 一 直 在 增加 ， 这 里 只 测试 了 发 送 200MB 左右 的 消息 ， 如 果 发 送 更 
多 的 消息 ， 那 么 这 个 堆 内 存 会 变 得 更 大 ， 直 到 出 现 java. Lang .OutOfMemoryError 的 报错 。 


这 个 内 存 洲 出 的 问题 可 以 使 用 Basic .Qos 来 得 到 有 效 的 解决 ,Basic.Qos 可 以 限制 某 个 
消费 者 所 保持 未 确认 消息 的 数量 ， 也 就 是 间接 地 限制 了 QueueingConsumer 中 的 
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LinkedBlockingQueue 的 大 小 。 注 意 一 定 要 在 调用 Basic.Consume 之 前 调用 Basic.Qos 
才能 生效 。 


QueueingConsumer 还 包含 (但 不 仅 限于 〉 以 下 一 些 缺 陷 : 
信 QueueingConsumer 会 拖累 同一 个 Connection 下 的 所 有 信道 ， 使 其 性 能 降低 ; 
信 同步 递归 调用 QueueingConsumer 会 产生 死 锁 ; 


令 RabbitMQ 的 自动 连接 恢复 机 制 Cautomatic connection recovery) 不 支持 Queueing 
Consumer 的 这 种 形式 ; 


信 QueueingConsumer 不 是 事件 驱动 的 。 


为 了 避免 不 必要 的 麻烦 ,建议 在 消费 的 时 候 尽 量 使 用 继承 DefaultConsumer 的 方式 , A 
体 使 用 方式 可 以 参考 代码 清单 1-2 和 代码 清单 3-9。 


4.10 ”消息 传输 保障 


消息 可 靠 传输 一 般 是 业务 系统 接 入 消息 中 间 件 时 首要 考虑 的 问题 ， 一 般 消 息 中 间 件 的 消息 
传输 保障 分 为 三 个 层级 。 


+ At most once: 最 多 一 次 。 消 息 可 能 会 丢失 ， 但 绝 不 会 重复 传输 。 
信 At least once: 最 少 一 次 。 消 息 绝 不 会 丢失 ， 但 可 能 会 重复 传输 。 
+ Exactly once: 恰好 一 次 。 每 条 消息 肯定 会 被 传输 一 次 且 仅 传输 一 次 。 


RabbitMQ 支持 其 中 的 “最 多 一 次 ”和 “最 少 一 次 ”。 其 中 “最 少 一 次 ”投递 实现 需要 考虑 
以 下 这 个 几 个 方面 的 内 容 : 


(1) 消息 生产 者 需要 开启 事务 机 制 或 者 publisher confirm 机 制 ， 以 确保 消息 可 以 可 靠 地 传 
输 到 RabbitMQ 中 。 


(2) 消息 生产 者 需要 配合 使 用 mandatory 参数 或 者 备份 交换 器 来 确保 消息 能 够 从 交换 器 
路 由 到 队列 中 ， 进 而 能 够 保存 下 来 而 不 会 被 丢弃 。 


G) 消息 和 队列 都 需要 进行 持久 化 处 理 ， 以 确保 RabbitMQ 服务 器 在 遇 到 异常 情况 时 不 会 
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造成 消息 丢失 。 


(4) 消费 者 在 消费 消息 的 同时 需要 将 autoAck 设置 为 false， 然 后 通过 手动 确认 的 方式 去 
确认 已 经 正确 消费 的 消息 ， 以 避免 在 消费 端 引起 不 必要 的 消息 丢失 。 

“最 多 一 次 ”的 方式 就 无 须 考 虑 以 上 那些 方面 ， 生 产 者 随意 发 送 ， 消 费 者 随意 消费 ， 不 过 这 
样 很 难 确保 消息 不 会 丢失 。 

“恰好 一 次 ”是 RabbitMQ 目前 无 法 保障 的 。 考 虑 这 样 一 种 情况 ， 消 费 者 在 消费 完 一 条 消息 
之 后 向 RabbitMQ 发 送 确认 Basic.Ack 命令 ， 此 时 由 于 网 络 断 开 或 者 其 他 原因 造成 RabbitMQ 
并 没有 收 到 这 个 确认 命令 ， 那 么 RabbitMQ 不 会 将 此 条 消息 标记 删除 。 在 重新 建立 连接 之 后 ， 
消费 者 还 是 会 消费 到 这 一 条 消息 ， 这 就 造成 了 重复 消费 。 再 考虑 一 种 情况 ， 生 产 者 在 使 用 
publisher confirm 机 制 的 时 候 ， 发 送 完 一 条 消息 等 待 RabbitMQ 返回 确认 通知 ， 此 时 网 络 断 开 ， 
生产 者 捕获 到 异常 情况 ， 为 了 确保 消息 可 靠 性 选择 重新 发 送 ， 这 样 RabbitMQ 中 就 有 两 条 同样 
的 消息 ， 在 消费 的 时 候 ， 消 费 者 就 会 重复 消费 。 

那么 RabbitMQ 有 没有 去 重 的 机 制 来 保证 “恰好 一 次 ? 呢 ? 答案 是 并 没有 ,不仅 是 RabbitMQ， 
目前 大 多 数 主 流 的 消息 中 间 件 都 没有 消息 去 重 机 制 ， 也 不 保障 “恰好 一 次 ” 去 重 处 理 一 般 是 在 
业务 客户 端 实现 ， 比 如 引入 GUID (Globally Unique Identifier) 的 概念 。 针 对 GUID， 如 果 从 客 
户 端的 角度 去 重 ， 那 么 需要 引入 集中 式 缓存 ， 必 然 会 增加 依赖 复杂 度 ， 另 外 缓存 的 大 小 也 难以 
界定 。 建 议 在 实际 生产 环境 中 ， 业 务 方 根据 自身 的 业务 特性 进行 去 重 ， 比 如 业务 消息 本 身 具备 
TEE, RAEE Redis 等 其 他 产品 进行 去 重 处 理 。 


411 小 结 


提升 数据 可 靠 性 有 以 下 一 些 途径 : 设置 mandatory 参数 或 者 备份 交换 器 (immediate 
参数 已 被 淘汰 ); 设置 publisher confirm 机 制 或 者 事务 机 制 ; 设置 交换 器 、 队 列 和 消息 都 为 持久 
化 ; 设置 消费 端 对 应 的 autoAck 参数 为 false 并 在 消费 完 消息 之 后 再 进行 消息 确认 。 本 章 不 仅 
介绍 了 数据 可 靠 性 的 一 些 细节 ， 还 展示 了 RabbitMQ 的 几 种 已 具备 或 者 衍生 的 高 级 特性 ， 包 括 
TTL、 死 信 队 列 、 延 迟 队 列 、 优 先 级 队列 、RPC 功能 等 ， 这 些 功能 在 实际 使 用 中 可 以 让 相应 应 
用 的 实现 变 得 事半功倍 。 
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到 目前 为 止 , 我 们 可 以 熟练 地 使 用 客户 端 程序 来 发 送 和 消费 消息 , 但 是 距离 掌控 RabbitMQ 
还 有 一 段 距离 。 本 章 会 从 服务 端的 角度 介绍 RabbitMQ 的 一 些 工具 应 用 ， 包括 rabbitmqctl 
工具 和 rabbitmq management 插件 。rabbitmqct1l 工具 是 一 个 系列 的 工具 ， 运 用 这 个 工 
具 可 以 执行 大 部 分 的 RabbitMQ 的 管理 操作 ,而 rabbitmq management 插件 是 RabbitMQ 提 
供 的 一 个 管理 插件 ,让 用 户 可 以 通过 图 形 化 的 方式 来 管理 RabbitMQ, 但 是 它 的 功能 却 远 不 仅 于 
此 ， 读 者 不 妨 逐 一 翻阅 本 章 的 内 容 来 寻找 答案 。 
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5.1 多 租户 与 权限 


每 一 个 RabbitMQ 服务 器 都 能 创建 虚拟 的 消息 服务 器 , 我 们 称 之 为 虚拟 主机 (virtual host)， 
简称 为 vhost。 每 一 个 vhost 本 质 上 是 一 个 独立 的 小 型 RabbitMQ 服务 器 , 拥有 自己 独立 的 队列 、 
交换 器 及 绑 定 关系 等 ， 并且 它 拥有 自己 独立 的 权限 。vhost 就 像 是 虚拟 机 与 物理 服务 器 一 样 ， 它 
们 在 各 个 实例 间 提 供 逻 辑 上 的 分 离 ， 为 不 同 程 序 安全 保密 地 运行 数据 ， 它 既 能 将 同一 个 
RabbitMQ 中 的 众多 客户 区 分 开 ， 又 可 以 避免 队列 和 交换 器 等 命名 冲突 。vhost 之 间 是 绝对 隔离 
的 ， 无 法 将 vhostl 中 的 交换 器 与 vhost2 中 的 队列 进行 绑 定 ， 这 样 既 保证 了 安全 性 ， 又 可 以 确保 
可 移植 性 。 如 果 在 使 用 RabbitMQ 达到 一 定 规 模 的 时 候 ， 建 议 用 户 对 业务 功能 、 场 景 进 行 归 类 
区 分 ， 并 为 之 分 配 独立 的 vhost。 


vhost 是 AMQP 概念 的 基础 ， 客 户 端 在 连接 的 时 候 必须 制定 一 个 vhost。RabbitMQ 默认 创 
建 的 vhost 为 “/”， 如 果 不 需 要 多 个 vhost 或 者 对 vhost 的 概念 不 是 很 理解 ， 那 么 用 这 个 默认 的 
vhost 也 是 非常 合理 的 ， 使 用 默认 的 用 户 名 guest 和 密码 guest 就 可 以 访问 它 。 但 是 为 了 安全 和 
方便 ， 建 议 重新 建立 一 个 新 的 用 户 来 访问 它 。 

可 以 使 用 rabbitmqctl add vhost {vhost} 命 令 创 建 一 个 新 的 vhost， 大 括号 里 的 参 
数 表 示 vhost 的 名 称 。 


示例 如 下 : 


[root@nodel ~]# rabbitmqctl add vhost vhostl 
Creating vhost "vhostl1" 


可 以 使 用 rabbitmqctl list vhosts [vhostinfoitem...] 来 罗列 当前 vhost 的 相 
关 信 息 。 目 前 vhostinfoitem 的 取 值 有 2 个 。 


* name: 表示 vhost 的 名 称 。 


* tracing: 表示 是 否 使 用 了 RabbitMQ 的 trace 功能 。 有 关 trace 功能 ， 详 细 可 以 参考 
11.1 Fe 


示例 如 下 : 


e93e 


RabbitMQ 实战 指南 


[root@nodel ~]# rabbitmqctl list vhosts name tracing 
Listing vhosts 

vhostl false 

/ false 

[root@nodel ~]# rabbitmqctl trace on 

Starting tracing for vhost "/" 

[root@nodel ~]# rabbitmqctl list vhosts name tracing 
Listing vhosts 

vhostl false 

/ true 


对 应 的 删除 vhost 的 命令 是 : rabbitmqctl delete vhost {vhost}， 其 中 大 括号 里 
面 的 参数 表示 vhost 的 名 称 。 删 除 一 个 vhost 同时 也 会 删除 其 下 所 有 的 队列 、 交 换 器 、 绑 定 关 系 、 
用 户 权 限 、 参 数 和 策略 等 信息 。 


示例 如 下 : 


[root@nodel ~]# rabbitmqctl delete vhost vhost1 
Deleting vhost "vhostl" 

[root@nodel ~]# rabbitmqctl list vhosts 
Listing vhosts 


AMQP 协议 中 并 没有 指定 权限 在 vhost 级 别 还 是 在 服务 器 级 别 实现 , 由 具体 的 应 用 自 定义 。 
在 RabbitMQ 中 ， 权 限 控 制 则 是 以 vhost 为 单位 的 。 当 创建 一 个 用 户 时 ， 用 户 通常 会 被 指派 给 至 
少 一 个 vhost， 并且 只 能 访问 被 指派 的 vhost 内 的 队列 、 交 换 器 和 绑 定 关系 等 。 因 此 ，RabbitMQ 
中 的 授予 权限 是 指 在 vhost 级 别 对 用 户 而 言 的 权限 授予 。 


相关 的 授予 权限 命令 为 : rabbitmqctl set permissions [-p vhost] (user) 
{conf} {write} {read}。 其 中 各 个 参数 的 含义 如 下 所 述 。 


$9 vhost: 授予 用 户 访 问 权限 的 vhost 名称， 可 以 设置 为 默认 值 ， 即 vhost 为 “/”。 
* user: 可 以 访问 指定 vhost 的 用 户 名 。 

信 conf: 一 个 用 于 匹配 用 户 在 哪些 资源 上 拥有 可 配置 权限 的 正则 表达 式 。 

信 write: 一 个 用 于 匹配 用 户 在 哪些 资源 上 拥有 可 写 权限 的 正则 表达 式 。 

信 read: 一 个 用 于 匹配 用 户 在 哪些 资源 上 拥有 可 读 权 限 的 正则 表达 式 。 


ik: 可 配置 指 的 是 队列 和 交换 器 的 创建 及 删除 之 类 的 操作 ; 可 写 指 的 是 发 布 消息 ; 可 读 指 
与 消息 有 关 的 操作 ， 包 括 读 取消 息 及 清空 整个 队列 等 。 
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表 5-1 中 展示 了 不 同 AMQP 命令 的 列表 和 对 应 的 权限 。 
表 5-1 AMQP 命令 与 权限 的 映射 关系 


AMaP 命令 
Exchange Declare (with AE) exchange(AE) 
MESES LES UR NM 


Exchange.Bind | 77] exchange (destination) exchange (source) 
Exchange.Unbind MENT exchange (destination) exchange (source) 












Queue.Declare (with DLX) 


授予 root 用 户 可 访问 虚拟 主机 vhostl , 并 在 所 有 资源 上 都 具备 可 配置 .可 写 及 可 读 的 权限 ， 
示例 如 下 : 


[root(nodel =]# rabbitmqctl set permissions =p vhostl root ".*" Vww m o*n 
Setting permissions for user "root" in vhost "vhostl" 


授予 root 用 户 可 访问 虚拟 主机 vhost2， 在 以 “queue” 开 头 的 资源 上 具备 可 配置 权限 ， 并 在 
所 有 资源 上 拥有 可 写 、 可 读 的 权限 ， 示 例如 下 : 


[root@nodel ~]# rabbitmqctl set permissions -p vhost2 root "^queue.*" ",*" ",x" 
Setting permissions for user "root" in vhost "vhost2" 


清除 权限 也 是 在 vhost 级 别 对 用 户 而 言 的 。 清 除权 限 的 命令 为 rabbitmqctl 
clear permissions [-p vhost] {username}。 其 中 vhost 用 于 设置 禁止 用 户 访 问 的 
虚拟 主机 的 名 称 ， 默 认为 “/” username 表示 禁止 访问 特定 虚拟 主机 的 用 户 名 称 。 


示例 如 下 : 


[root@nodel ~]# rabbitmqctl clear permissions -p vhostl root 
Clearing permissions for user "root" in vhost "vhostl" 
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在 RabbitMQ 中 有 两 个 Shell 命令 可 以 列举 权限 信息 。 第 一 个 命令 是 rabbitmqctl 
list permissions [-p vhost]， 用 来 显示 虚拟 主机 上 的 权限 ; 第 二 个 命令 是 
rabbitmqctl list user permissions {username}， 用 来 显示 用 户 的 权限 。 


示例 如 下 : 


[root@nodel ~]# rabbitmqctl list permissions -p vhostl 
Listing permissions in vhost "vhostl" 

root QA am o 

[root@nodel ~]# rabbitmqctl list user permissions root 


Listing permissions for user "root" 
/ SE RW uu 


vhostdi iS jg* ,* 


细心 的 读者 可 能 会 注意 到 本 节 中 用 到 的 所 有 命令 都 是 rabbitmqctl 工具 的 扩展 命令 ， 
rabbitmqctl 工具 是 用 来 管理 RabbitMQ 中 间 件 的 命令 行 工 具 , 它 通过 连接 各 个 RabbitMQ 节 
点 来 执行 所 有 操作 。 如 果 有 节点 没有 运行 ， 将 显示 诊断 信息 : 不 能 到 达 或 因 不 匹配 的 Erlang 
cookie (X Erlang cookie 的 细节 可 以 参考 7.1 节 ) 而 拒绝 连接 。 


rabbitmqctl 工具 的 标准 语法 如 下 [] 表示 可 选 参数 ，{ } 表示 必 选 参数 ): 


rabbitmqctl [-n node] [-t timeout] [-q] (command) [command options...] 


[-n node] 


默认 节点 是 “rabbit@hostname” 此 处 的 hostname 是 主机 名 称 。 在 一 个 名 为 “node.hidden.com” 
的 主机 上 ，RabbitMQ 节点 的 名 称 通常 是 rabbit@node (除非 RABBITMO NODENAME 参数 在 启 
动 时 被 设置 成 了 非 默 认 值 ) 。hostname -s 命令 的 输出 通常 是 “@” 标 志 后 的 东西 。 
[-q] 
.使 用 -q 标志 来 启用 quiet 模式 ， 这 样 可 以 屏蔽 一 些 消息 的 输出 。 默认 不 开启 quiet 模式 。 


[-t timeout] 
操作 超时 时 间 ( 秒 为 单位 )， 只 适用 于 “1ist xxx” 类 型 的 命令 ， 默 认 是 无 穷 大 。 
下 面 来 演示 [-q] 和 [-t timeout] 参 数 的 用 法 和 效果 : 


[root@nodel ~]# rabbitmqctl list vhosts 
Listing vhosts 

/ 

[root@nodel ~]# rabbitmqctl list vhosts -q 
/ 
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[root(nodel ~]# rabbitmqctl list vhosts =q -t 1 
/ 

[root@nodel ~]# rabbitmqctl list vhosts -q -t 0 
Error: (timeout,0.0)] 


5.2 ”用 户 管理 


在 RabbitMQ 中 ， 用 户 是 访问 控制 (Access Control) 的 基本 单元 ， 且 单个 用 户 可 以 跨越 多 
个 vhost 进行 授权 。 针 对 一 至 多 个 vhost， 用 户 可 以 被 赋予 不 同 级 别 的 访问 权限 ， 并 使 用 标准 的 
用 户 名 和 密码 来 认证 用 户 。 


创建 用 户 的 命令 为 rabbitmqctl add user (username) (password). 。 其 中 
username 表示 要 创建 的 用 户 名 称 ; password 表示 创建 用 户 登 录 的 密码 。 


具体 创建 一 个 用 户 名 为 root、 密 码 为 root123 的 用 户 : 


[root@nodel ~]# rabbitmqctl add user root root123 
Creating user "root" 


可 以 通过 rabbitmqctl change password (username) {newpassword} 命 令 来 更 
改 指 定 用户 的 密码 ， 其 中 username 表示 要 变更 密码 的 用 户 名 称 ，newpassword 表示 要 变更 
的 新 的 密码 。 


举例 ， 将 root 用 户 的 密码 变更 为 root321; 


[rooténodel ~]# rabbitmqctl change password root root321 
Changing password for user "root" 


同样 可 以 清除 密码 ， 这 样 用 户 就 不 能 使 用 密码 登录 了 ， 对 应 的 操作 命令 为 rabbitmqctl 
clear password (username), X" username 表示 要 清除 密码 的 用 户 名 称 。 


使 用 rabbitmqctl authenticate user (username) {password} 可 以 通过 密码 
来 验证 用 户 ， 其 中 username 表示 需要 被 验证 的 用 户 名 称 ，password 表示 密码 。 


下 面 示例 中 分 别 采用 root321 和 root322 来 验证 root 用 户 : 


[root@nodel ~]# rabbitmqctl authenticate user root root321 
Authenticating user "root" 
Success 
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[root@nodel ~]# rabbitmqctl authenticate user root root322 
Authenticating user "root" 
Error: failed to authenticate user "root" 


删除 用 户 的 命令 是 rabbitmqctl delete user (username), H} username 表示 
要 删除 的 用 户 名 称 。 
删除 root 用 户 的 示例 如 下 : 


[rootGnodel ~]# rabbitmqctl delete user root 
Deleting user "root" 


rabbitmqctl list users 命令 可 以 用 来 罗列 当前 的 所 有 用 户 。 每 个 结果 行 都 包含 用 户 
名 称 ， 其 后 紧 跟 用 户 的 角色 (tags)。 
示例 如 下 : 


[root@nodel ~]# rabbitmqctl list users 
Listing users 

guest [administrator] 

root [] 


用 户 的 角色 分 为 5 种 类 型 。 
* none: 无 任何 角色 。 新 创建 的 用 户 的 角色 默认 为 none。 
* management: 可 以 访问 Web 管理 页 面 。Web 管理 页 面 在 5.3 节 中 会 有 详细 介绍 。 


* policymaker: AA management 的 所 有 权限 ， 并 且 可 以 管理 策略 (Policy) 和 参数 
(Parameter)。 详 细 内 容 可 参考 6.3 节 。 

+ monitoring: 包含 management 的 所 有 权限 ， 并 且 可 以 看 到 所 有 连接 、 信 道 及 节点 
相关 的 信息 。 

€ administartor: 包含 monitoring 的 所 有 权限 ， 并 且 可 以 管理 用 户 、 虚 拟 主机 、 
权限 、 策 略 、 参 数 等 。administator 代表 了 最 高 的 权限 。 


用 户 的 角色 可 以 通过 rabbitmqctl set user tags (username) (tag ...]} 命 令 
设置 。 其 中 username 参数 表示 需要 设置 角色 的 用 户 名 称 ;，tag 参数 用 于 设置 0 个 、1 个 或 者 
多 个 的 角色 ， 设 置 之 后 任何 之 前 现 有 的 身份 都 会 被 删除 。 


示例 如 下 : 


[root@nodel ~]# rabbitmqctl set user tags root monitoring 
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Setting tags for user "root" to [monitoring] 

[root(nodel ~]# rabbitmqctl list users -q 

guest [administrator] 

root [monitoring] 

[root(nodel ~]# rabbitmqctl set user tags root policymaker -q 
[root(nodel ~]# rabbitmqctl list users -q 

guest [administrator] 

root [policymaker] 

[root(nodel ~]# rabbitmqctl set user tags root 

Setting tags for user "root" to [] 

[root(nodel ~]# rabbitmqctl list users -q 

guest [administrator] 

root [4 

[root(nodel ~]# rabbitmqctl set user tags root policymaker,management 
Setting tags for user "root" to ['policymaker,management'] 
[root(nodel ~]# rabbitmqctl list users -q 

guest [administrator] 

root [policymaker,management] 





5.3 Web 端 管理 


前 面 讲述 的 都 是 使 用 rabbitmqctl 工具 来 管理 RabbitMQ， 有 些 时 候 是 否 会 觉得 这 种 方 
式 是 不 是 不 太 友 好 ? 而 且 为 了 能 够 运行 rabbitmqctl 工具 ， 当 前 的 用 户 需要 拥有 访问 Erlang 
cookie 的 权限 ， 由 于 服务 器 可 能 是 以 guest 或 者 root 用 户 身 份 来 运行 的 ， 因 此 你 需要 获得 这 些 
文件 的 访问 权限 ， 这 样 就 引申 出 来 一 些 权 限 管 理 的 问题 。 


RabbitMQ 的 开发 团队 也 考虑 到 了 这 种 情况 ， 并 且 开 发 了 RabbitMQ management 插件 。 
RabbitMQ management 插件 同样 是 由 Erlang 语言 编写 的 ， 并 且 和 RabbitMQ 服务 运行 在 同一 个 
Erlang 虚拟 机 中 。 


RabbitMQ management 插件 可 以 提供 Web 管理 界面 用 来 管理 如 前 面 所 述 的 虚拟 主机 、 用 
户 等 ， 也 可 以 用 来 管理 队列 、 交 换 器 、 绑 定 关 系 、 策 略 、 参 数 等 ， 还 可 以 用 来 监控 RabbitMQ 
服务 的 状态 及 一 些 数据 统计 类 信息 , 可 谓 是 功能 强大 , 基本 上 能 够 涵盖 所 有 RabbitMQ 管理 的 
功能 。 


在 使 用 Web 管理 界面 之 前 需要 先 启用 RabbitMQ management 插件 。RabbitMQ 提供 了 很 多 
的 插件 ， 默 认 存放 在 SRABBITMO HOME/plugins 目录 下 ， 如 下 所 示 。 
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[rootGnodel Plugins]# ls -al 


-rw-r--r-- 


-pwepeerne- i 
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amqp client-3.6.10.ez 

cowboy-1.0.4.ez 

cowlib-1.0.2.ez 

rabbit common-3.6.10.ez 
rabbitmq amqpl 0-3.6.10.ez 

rabbitmq auth backend ldap-3.6.10.ez 
rabbitmq auth mechanism ss1-3.6.10.ez 
rabbitmq consistent hash exchange-3.6.10.ez 
rabbitmq event exchange-3.6.10.ez 
rabbitmq federation-3.6.10.ez 

rabbitmq federation management-3.6.10.ez 
rabbitmq jms topic exchange-3.6.10.ez 
rabbitmq management-3.6.10.ez 

rabbitmq management agent-3.6.10.ez 
rabbitmq management visualiser-3.6.10.ez 
rabbitmq mqtt-3.6.10.ez 

rabbitmq recent history exchange-3.6.10.ez 
rabbitmq sharding-3.6.10.ez 

rabbitmq shovel-3.6.10.ez 

rabbitmq shovel management-3.6.10.ez 
rabbitmq stomp-3.6.10.ez 

rabbitmq top-3.6.10.ez 

rabbitmq tracing-3.6.10.ez 
rabbitmq trust store-3.6.10.ez 
rabbitmq web dispatch-3.6.10.ez 
rabbitmq web mqtt-3.6.10.ez 

rabbitmq web mqtt examples-3.6.10.ez 
rabbitmq web stomp-3.6.10.ez 

rabbitmq web stomp examples-3.6.10.ez 
ranch-1.3.0.ez 

README 


Sockjs-0.3.4.ez 


其 中 以 .ez 扩展 名 称 结 尾 的 文件 就 是 RabbitMQ 的 插件 ， 上 面 文件 中 的 
rabbitmq management-3.6.10.ez 就 是 指 RabbitMQ Management 插件 。 启 动 插 件 的 命令 
不 是 使 用 rabbitmqctl 工具 ， 而 是 使 用 rabbitmq-plugins, ， 其 语法 格式 为 : 
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rabbitmq-plugins [-n node] (command) [command options...]。 启 动 插件 是 使 
Ħ rabbitmq-plugins enable [plugin-name], 关 闭 插 件 的 命令 是 rabbitmq-plugins 


disable [plugin-name]. 


执行 rabbitmq-plugins enable rabbitmq management 命令 来 开启 RabbitMQ 
managmenet 插件 : 


[root@nodel ~]# rabbitmq-plugins enable rabbitmq management 

The following plugins have been enabled: 

amqp client 

cowlib 

cowboy 

rabbitmq web dispatch 

rabbitmq management agent 

rabbitmq management 

Applying plugin configuration to rabbit(üénodel... started 6 plugins. 


可 以 通过 rabbitmq-plugins list 命令 来 查看 当前 插件 的 使 用 情况 ， 如 下 所 示 。 其 中 
标记 为 [E* ] 的 为 显 式 启动 ， 而 [e* ] 为 隐 式 启动 ， 如 显 式 启动 rabbitmq management 插件 
会 同时 隐 式 启动 amqp client. cowboy. cowlib、 rabbitmq management agent, 
rabbitmq web dispatch 等 另外 5 个 插件 。 


[rootünodel ~]# rabbitmq-plugins list 

Configured: E = explicitly enabled; e = implicitly enabled 
Status: * = running on rabbitG8nodel 

/ 

[e*] amqp client 3.6.10 

[e*] cowboy 1.0.4 

[e*] cowlib 1.0.2 

[ rabbitmq amqpl 0 3.6.10 

rabbitmq event exchange 3.6.10 

rabbitmq federation 3.6.10 

rabbitmq federation management 3.6.10 
rabbitmq jms topic exchange 3.6.10 

E*] rabbitmq management 3.6.10 

e*] rabbitmq management agent 3.6.10 

] rabbitmq management visualiser 3.6.10 

] rabbitmq sharding 3.6.10 

] rabbitmq shovel 3.6.10 

] rabbitmq shovel management 3.6.10 

] rabbitmq stomp 3.6.10 
] 
] 
* 





— — — 


rabbitmq top 3.6.10 
rabbitmq tracing 3.6.10 


[ 
[ 
[ 
[ 
[ 
[ 
[ 
[ 
[ 
[ 
[ 
[ 
[ 
[e*] rabbitmq web dispatch 3.6.10 
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(省 略 若 干 项 …) 


开启 rabbitmq management 插件 之 后 还 需要 重启 RabbitMQ 服务 才能 使 其 正式 生效 。 
之 后 就 可 以 通过 浏览 器 访问 http:/Wlocalhost:15672/， 这 样 会 出 现 一 个 认证 登录 的 界面 ， 可 以 通过 
默认 的 guest/guest 的 用 户 名 和 密码 来 登录 。 如 果 访 问 的 他 地 址 不 是 本 地 地 址 , 比如 在 192.168.0.2 
的 主机 上 访问 http://192.168.0.3:15672 的 Web 管理 页 面 ， 使 用 默认 的 guest 账户 是 访问 不 了 的 。 
在 之 前 比较 古老 的 版 本 中 可 以 访问 ， 但 是 出 于 安全 性 方面 的 考虑 ， 在 最 近 的 一 些 版 本 中 需要 使 
用 一 个 具有 非 none 的 用 户 角色 的 非 guest 账户 来 访问 Web 管理 页 面 。 


顺利 登录 之 后 ， 可 以 看 到 Web 管理 的 主 界面 如 图 5-1 所 示 。 
由 RabbitMQ enet (aaran) i 


Custer: ri 1 
RabbitMQ 3.6.10, Erlang 19.1 
Connections. Channels. Exchanges Virtual host: | AN * 
Overview 
* Totais 


Queved messages (chart: last minute) (0) 
2$ ES 


so 
15 


00 








11:35:00 11:35:10 11:35:20 11:35:30 11:35:40 11:38:50 





| 


 —-—————— | 
11:35:0011:35:10 11:35:20 11:35:30 11:35:40 11:25:50 


0.0/s' 


file descriptors (°) Socket descriptors (^) Erlang processes. Disk space. Ratesmode Info Reset stats DG +/ 
à i EE RA aa) 
quem. i ri n į j 
babe en i MINUM | Je R. MR dl pem c o oi d] goce 
no 
1024 available 829 avallabie 1048376 avellabie 3.168 high watermarféMB low watermark 


zo 





5-1 iri 


52 节 中 介绍 了 如 何 新 增 、 删 除 、 查 看 用 户 等 管理 功能 ， 那 么 通过 Web 管理 界面 同样 可 以 
做 到 ， 具 体 如 图 5-2 所 示 。 


在 图 5-2 中 可 以 看 到 当前 的 用 户 为 guest 和 root， 都 被 赋予 了 administrator 的 权限 ， 在 页 
面 的 下 方 可 以 添加 用 户 。 点击 任 意 用 户 可 以 进入 相关 的 详细 页 面 如 图 5-3 所 示 , 在 此 页 面 中 
可 以 为 用 户 设置 权限 和 清除 权限 , 也 可 以 删除 或 者 更 新 用 户 , 更 新 用 户 是 指 更 新 用 户 的 密码 
和 角色 。 
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E Regex (?)?) 


* (confirm) 


iQ 
Set Admin | Monitoring | Policymaker | Management | Impersonator | None 








b Update this user 


> Delete this user 





图 5-3 ”详细 页 面 
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5.1 节 中 提 及 了 关于 多 租户 的 概念 及 相应 的 管理 操作 ， 同 样 如 图 5-4 所 示 ， 在 此 页 面 中 可 以 
添加 相应 的 虚拟 主机 。 


£ Regex (?)(?) 


Messages Message rates +/- 
Name  Users(?) Ready  Unacked Total publish deliver / get 


$ 


/ | guest, root Z5 9 7 0.00/s 0.00/s 


* Adda new virtual host 





5-4 虚拟 主机 


点 击 列表 中 的 虚拟 主机 也 可 以 进入 相对 应 的 虚拟 主机 的 详细 页 面 , 在 此 详细 页 面 中 可 以 查看 
队列 、 消 息 的 详细 统计 信息 ， 也 可 以 对 用 户 和 权限 进行 管理 操作 ， 还 可 以 删除 当前 的 虚拟 主机 。 


对 于 Web 管理 页 面 的 其 他 功能 ， 比 如 创建 和 删除 队列 、 交 换 器 、 绑 定 关 系 、 参 数 和 策略 等 
操作 会 在 后 面 的 介绍 中 提 及 。 


最 后 补充 一 下 与 开启 rabbitmq management 插件 对 应 的 关闭 命令 是 rabbitmq- 
pluginsdisable rabbitmq management， 示 例 参考 如 下 : 


[root@nodel ~]# rabbitmq-plugins disable rabbitmq management 

The following plugins have been disabled: 

amqp client 

cowlib 

cowboy 

rabbitmq web dispatch 

rabbitmq management agent 

rabbitmq management 

Applying plugin configuration to rabbit(ünodel... stopped 6 plugins. 


某 些 情况 下 ， 登 录 Web 管理 界面 会 出 现 如 图 5-5 中 的 情形 一 一 用 户 能 够 正确 登录 ， 但 是 除 
了 页 面 头 部 和 尾部 没有 任何 其 它 内 容 呈 现 。 此 时 清空 下 浏览 器 的 缓存 即 可 。 
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ah R d bb it M Q Cluster: CENA poak Log out 


HTTP API | Command Line 





5-5 ”异常 情况 处 理 


5.4 ”应 用 与 集群 管理 


本 节 主 要 阐述 应 用 与 集群 相关 的 一 些 操作 管理 命令 ， 包 括 关 闭 、 重 置 、 开 启 服务 ， 还 有 建 
立 集群 的 一 些 信 息 。 有 关 集 群 搭建 更 多 的 信息 可 以 参考 7.1 节 。 


54.1 应 用 管理 


rabbitmqctl stop [pid file] 


用 于 停止 运行 RabbitMQ 的 Erlang 虚拟 机 和 RabbitMQ 服务 应 用 。 如 果 指 定 了 pid file, 
还 需要 等 待 指定 进程 的 结束 。 其 中 pid file 是 通过 调用 rabbitmq-server 命令 启动 
RabbitMQ 服务 时 创建 的 ,默认 情况 下 存放 于 Mnesia 目录 中 ,可 以 通过 RABBITMO PID FILE 
这 个 环境 变量 来 改变 存放 路 径 。 注 意 ， 如 果 使 用 rabbitmq-server -detach 这 个 带 有 
-detach 后 缀 的 命令 来 启动 RabbitMQ 服务 则 不 会 生成 pid_file 文 件 。 


示例 如 下 : 


[root@nodel ~]# rabbitmqctl stop 
/opt/rabbitmq/var/lib/rabbitmqg/mnesia/rabbitNGnodel.pid 

Stopping and halting node rabbitG8nodel 

[root8nodel ~]# rabbitmqctl stop 

Stopping and halting node rabbitG8nodel 


rabbitmqctl shutdown 


用 于 停止 运行 RabbitMQ 的 Erlang 虚拟 机 和 RabbitMQ 服务 应 用 。 执 行 这 个 命令 会 阻塞 直 
到 Erlang 虚拟 机 进程 退出 。 如 果 RabbitMQ 没有 成 功 关 闭 ， 则 会 返回 一 个 非 零 值 。 这 个 命令 和 
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rabbitmqctl stop 不 同 的 是 ， 它 不 需要 指定 pid_file 而 可 以 阻塞 等 待 指定 进程 的 关闭 。 
示例 如 下 : 


[root@nodel ~]# rabbitmqctl shutdown 

Shutting down RabbitMQ node rabbit@nodel running at PID 1706 

Waiting for PID 1706 to terminate 

RabbitMQ node rabbitG8nodel running at PID 1706 successfully shut down 


rabbitmqctl stop app 


停止 RabbitMQ 服务 应 用 ， 但 是 Erlang 虚拟 机 还 是 处 于 运行 状态 。 此 命令 的 执行 优先 于 其 
他 管理 操作 〈 这 些 管理 操作 需要 先 停 止 RabbitMQ 应 用 )， 比 如 rabbitmqctl reset. 


示例 如 下 : 
[root@nodel ~]# rabbitmqctl stop app 
Stopping rabbit application on node rabbit nodel 


rabbitmqctl start app 


启动 RabbitMQ 应 用 。 此 命令 典型 的 用 途 是 在 执行 了 其 他 管理 操作 之 后 ， 重 新 启动 之 前 停 
止 的 RabbitMQ 应 用 ， 比 如 rabbitmqctl reset. 


示例 如 下 : 


[root@nodel ~]# rabbitmqctl start app 
Starting node rabbitGnodel 


rabbitmqctl wait [pid file] 


等 待 RabbitMQ 应 用 的 启动 。 它 会 等 到 pid_file 的 创建 ， 然 后 等 待 pid_file 中 所 代表 
的 进程 启动 。 当 指定 的 进程 没有 启动 RabbitMQ 应 用 而 关闭 时 将 会 返回 失败 。 


示例 如 下 : 


[root@nodel ~]# rabbitmqctl wait 
/opt/rabbitmq/var/lib/rabbitmq/mnesia/rabbit\@nodel .pid 

Waiting for rabbit@nodel 

pid is 3468 

[root@nodel ~]# rabbitmqctl wait 
/opt/rabbitmq/var/lib/rabbitmq/mnesia/rabbit\@nodel .pid 

Waiting for rabbit@nodel 

pid is 3468 

Error: process not running 
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rabbitmqctl reset 


将 RabbitMQ 节点 重 置 还 原 到 最 初 状 态 。 包 括 从 原来 所 在 的 集群 中 删除 此 节点 ， 从 管理 数据 库 
中 删除 所 有 的 配置 数据 ， 如 已 配置 的 用 户 、vhost 等 ， 以 及 删除 所 有 的 持久 化 消息 。 执 行 
rabbitmqctl reset 命令 前 必须 停止 RabbitMQ 应 用 (比如 先 执行 rabbitmqctl stop app). 


示例 如 下 : 


[root@nodel ~]# rabbitmqctl stop app 

Stopping rabbit application on node rabbitG8nodel 
[root@nodel ~]# rabbitmqctl reset 

Resetting node rabbit@node 


rabbitmqctl force reset 


强制 将 RabbitMQ 节点 重 置 还 原 到 最 初 状态 。 不 同 于 rabbitmqctl reset MẸ, 
rabbitmqctl force reset 命令 不 论 当前 管理 数据 库 的 状态 和 集群 配置 是 什么 ， 都 会 无 条 
件 地 重 置 节点 。 它 只 能 在 数据 库 或 集群 配置 已 损坏 的 情况 下 使 用 。 与 rabbitmqctl reset 
命令 一 样 ， 执 行 rabbitmqctl force reset 命令 前 必须 先 停止 RabbitMQ 应 用 。 


示例 如 下 : 


[root@nodel ~]# rabbitmqctl stop app 

Stopping rabbit application on node rabbit8nodel 
[rootGnodel ~]# rabbitmqctl force reset 
Forcefully resetting node rabbitGnodel 


rabbitmqctl rotate logs (suffix) 


指示 RabbitMQ 节点 轮换 日 志文 件 .RabbitMQ 节点 会 将 原来 的 日 志文 件 中 的 内 容 追 加 到 ”* 原 
始 名 称 + 后 缀 ”的 日 志文 件 中 ， 然 后 再 将 新 的 日 志 内 容 记 录 到 新 创建 的 日 志 中 《与 原 日 志文 件 同 
名 )。 当 目标 文件 不 存在 时 ， 会 重新 创建 。 如 果 不 指定 后 缀 suffix， 则 日 志文 件 只 是 重新 打开 
而 不 会 进行 轮换 。 

示例 如 下 所 示 ， 原 日 志文 件 为 rabbit@nodel.log 和 rabbit@nodel-sasl.log， 轮 换 日 志 之 后 ， 
原 日 志文 件 中 的 内 容 就 被 追加 到 rabbit@nodel.log.1 和 rabbit@nodel-sasl.log.1 日 志 中 ， 之 后 重 
新 建立 rabbit@node1.log 和 rabbit()nodel-sasl.log 文件 用 来 接收 新 的 日 志 。 


[root@nodel rabbitmq]# pwd 
/opt/rabbitmq/var/log/rabbitmq 
[root@nodel rabbitmq]# 11 
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-rw-r--r-- 1 root root 1024127 Oct 18 11:56 rabbit@nodel.log 
-rw-r--r-- 1 root root 720553 Oct 17 19:16 rabbitG8nodel-sasl.log 
[root(nodel rabbitmq]f rabbitmqctl rotate logs .1 

Rotating logs to files with suffix ".1" 

[rootGnodel rabbitmq]s4 11 


-fw-r--r-- 1 root root 0 Oct 18 12:05 rabbit8nodel.log 
-rw-r--r-- 1 root root 1024202 Oct 18 12:05 rabbite(nodel.log.1 
Ofw-f--r-- 1l root. root 0 Oct 18 12:05 rabbit8énodel-sasl.log 


-rw-r--r-- 1 root root 720553 Oct 18 12:05 rabbitü8nodel-sasl.log.1 
rabbitmqctl hipe compile (directory) 


将 部 分 RabbitMQ 代码 用 HiPE (HiPE 是 指 High Performance Erlang, Jé Erlang 版 的 JIT) 
编译 ， 并 且 将 编译 后 的 .beam 文件 (beam 文件 是 Erlang 编译 器 生成 的 文件 格式 ， 可 以 直接 加 载 
到 Erlang 虚拟 机 中 运行 的 文件 格式 ) 保存 到 指定 的 文件 目录 中 。 如 果 这 个 目录 不 存在 则 会 自行 
创建 。 如 果 这 个 目录 中 原本 有 任何 .beam 文件 ， 则 会 在 执行 编译 前 被 删除 。 如 果 要 使 用 预 编译 
的 这 些 文件 ， 则 需要 设置 RABBITMO SERVER CODE PATH 这 个 环境 变量 来 指定 hipe compile 
调用 的 路 径 。 


示例 如 下 : 


[root@nodel rabbitmq]# rabbitmqctl hipe compile 
/opt/rabbitmqg/tmp/rabbit-hipe/ebin 
MOPE SONDILINgS | | 
| EEE HEHE FE FE AE AE AE AE AE FE FE FE FE FE AE TE AE AE HE FE E FE AE FE AE FE AE AE AE E E E TE TE TETEE EAE | 
Compiled 57 modules in 55s 


5.4.2 ”集群 管理 


rabbitmqctl join cluster (cluster node) [--ram] 


将 节点 加 入 指定 集群 中 。 在 这 个 命令 执行 前 需要 停止 RabbitMQ 应 用 并 重 置 节点 。 更 多 详 
细 内 容 请 参考 7.1 节 。 


rabbitmqctl cluster status 
显示 集群 的 状态 。 更 多 详细 内 容 请 参考 7.1 节 。 


rabbitmqctl change cluster node type (disc|ram) 
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修改 集群 节点 的 类 型 。 在 这 个 命令 执行 前 需要 停止 RabbitMQ 应 用 。 更 多 详细 内 容 可 参考 
7.4 B. 


rabbitmqctl forget cluster node [--offline] 
将 节点 从 集群 中 删除 ， 人 允许 离线 执行 。 更 多 详细 内 容 请 参考 71. 
rabbitmqctl update cluster nodes (clusternode) 


在 集群 中 的 节点 应 用 启动 前 咨询 clusternode 节点 的 最 新 信息 , 并 更 新 相应 的 集群 信息 。 
这 个 和 join cluster 不同 ， 它 不 加 入 集群 。 考 虑 这 样 一 种 情况 ， 节 点 A 和 节点 B 都 在 集群 
中 ， 当 节点 A 离线 了 ， 节 点 C 又 和 节点 B 组 成 了 一 个 集群 ， 然 后 节点 B 又 离开 了 集群 ， 当 A 
醒 来 的 时 候 ， 它 会 尝试 联系 节点 B， 但 是 这 样 会 失败 ， 因 为 节点 B 已 经 不 在 集群 中 了 。 
Rabbitmqctl update cluster nodes -n A C 可 以 解决 这 种 场景 下 出 现 的 问题 。 


示例 如 下 : 


## 假 设 已 有 nodel 和 node 组 成 的 集群 

HL .初始 状态 

[rootQnodel ~]# rabbitmqctl cluster status 

Cluster status of node rabbit(nodel 

[(nodes, [(disc, [rabbitG8ünodel,rabbit8node2]]]), 
(running nodes, [rabbit8node2,rabbit8nodel]], 
(cluster name,««"rabbit8nodel"»»], 
(partitions,[]), 
(alarms,[(rabbit8node2,[]),(rabbitGnodel,[])1)] 

12 .关闭 node 节点 的 应 用 

[root@nodel ~]# rabbitmqctl stop app 

Stopping rabbit application on node rabbit8nodel 

##3 .之 后 将 node3 加 入 到 集群 中 (rabbitmqctl join cluster rabbit@node2) 
##4 .再 将 node2 节点 的 应 用 关闭 

##5 .最 后 启动 nodel 节点 的 应 用 ， 此 时 会 报错 

[root@nodel ~]# rabbitmqctl start app 

Starting node rabbit@nodel 

BOOT FAILED 


Timeout contacting cluster nodes: [rabbitGnode2]. 


##6 .如 果 在 启动 nodel 节点 的 应 用 之 前 咨询 node3 并 更 新 相关 集群 信息 则 可 以 解决 这 个 问题 
[root@nodel ~]# rabbitmqctl update cluster nodes rabbitenode3 
Updating cluster nodes for rabbit@nodel from rabbit@node3 

[root@nodel ~]# rabbitmqctl start app 

Starting node rabbit@nodel 
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##7 .最 终 集群 状态 

[root@nodel ~]# rabbitmqctl cluster status 

Cluster status of node rabbitünodel 

[(nodes, [ (disc, [rabbitGnodel,rabbit8node3]]1), 
(running nodes, [rabbitG8node3,rabbit8nodel]], 
(cluster name,««"rabbit8nodel"»»], 
(partitions, L] ¥ə 

{alarms, [{rabbit@node3, []}, {rabbit@nodel,[]}]}] 


rabbitmqctl force_boot 


确保 节点 可 以 启动 ， 即 使 它 不 是 最 后 一 个 关闭 的 节点 。 通 常情 况 下 ， 当 关闭 整个 RabbitMQ 
集群 时 , 重启 的 第 一 个 节点 应 该 是 最 后 关闭 的 节点 , 因为 它 可 以 看 到 其 他 节点 所 看 不 到 的 事情 。 
但 是 有 时 会 有 一 些 异 常情 况 出 现 ， 比 如 整个 集群 都 掉 电 而 所 有 节点 都 认为 它 不 是 最 后 一 个 关闭 
的 。 在 这 种 情况 下 ， 可 以 调用 rabbitmqctl force boot 命令 ， 这 就 告诉 节点 可 以 无 条 件 
地 启动 节点 。 在 此 节点 关闭 后 ， 集 群 的 任何 变化 ， 它 都 会 丢失 。 如 果 最 后 一 个 关闭 的 节点 永久 
丢失 了 ， 那 么 需要 优先 使 用 rabbitmqctl forget cluster node --offline 命令 ， 因 
为 它 可 以 确保 镜像 队列 的 正常 运转 。 


示例 如 下 : 


[root@node2 ~]# rabbitmqctl force boot 
Forcing boot for Mnesia dir /opt/rabbitmqg/var/lib/rabbitmq/mnesia/rabbit8node2 
[root@node2 ~]# rabbitmq-server -detached 


rabbitmqctl sync queue [-p vhost] (queue) 

指示 未 同步 队列 queue 的 slave 镜像 可 以 同步 master 镜像 行 的 内 容 。 同 步 期 间 此 队列 会 被 
阻塞 (所 有 此 队列 的 生产 消费 者 都 会 被 阻塞 )， 直 到 同步 完成 。 此 条 命令 执行 成 功 的 前 提 是 队列 
queue 配置 了 镜像 。 注 意 ， 未 同步 队列 中 的 消息 被 耗 尽 后 ， 最 终 也 会 变 成 同步 ， 此 命令 主要 用 
于 未 耗 尽 的 队列 。 更 多 细节 可 以 参考 9.4 节 。 


示例 如 下 : 


[root@nodel ~]# rabbitmqctl sync queue queue 
Synchronising queue 'queue' in vhost '/' 


rabbitmqctl cancel sync queue [-p vhost] (queue) 


取消 队列 queue 同步 镜像 的 操作 。 
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示例 如 下 : 


[root@nodel ~]# rabbitmqctl cancel sync queue queue 
Stopping synchronising queue 'queue' in vhost '/' 


rabbitmqctl set cluster name (name) 


设置 集群 名 称 。 集 群 名 称 在 客户 端 连接 时 会 通报 给 客户 端 。Federation 和 Shovel 插件 也 会 


有 用 到 集群 名 称 的 地 方 , 详细 内 容 可 以 参考 第 8 章 。 集 群 名 称 默认 是 集群 中 第 一 个 节点 的 名 称 ， 
通过 这 个 命令 可 以 重新 设置 。 在 Web 管理 界面 的 右上 角 〈 可 参考 图 5-1) 有 个 “(change)” 的 
地 方 ， 点 击 也 可 以 修改 集群 名 称 。 


示例 如 下 : 


[root@nodel ~]# rabbitmqctl cluster status 
Cluster status of node rabbit nodel 
[(nodes, [(disc, [rabbitGnodel,rabbit8node2])]1]), 

(running nodes, [rabbit8node2, rabbit8nodel]], 

(cluster name,<<"rabbit@nodel">>}, 

(partitions, [1], 

(alarms, [(rabbitG8node2,[]), (rabbitG8nodel, [1)1)] 
[rooténodel ~]# rabbitmqctl set cluster name cluster hidden 
Setting cluster name to cluster hidden 
[rooténodel ~]# rabbitmqctl cluster status 
Cluster status of node rabbit(nodel 
[(nodes, [(disc, [rabbitGnodel,rabbit8node2])]]), 

(running nodes, [rabbit node2, rabbit8nodel]], 

(cluster name,««"cluster hidden">>}, 

(partitions,[]], 

(alarms, [(rabbitG8node2, []), (rabbit8nodel, [])1)] 


5.5 ”服务 端 状 态 


服务 器 状态 的 查询 会 返回 一 个 以 制 表 符 分 隔 的 列表 , list queues.list exchanges. 


list bindings 和 list_consumers 这 种 命令 接受 一 个 可 选 的 vhost 参数 以 显示 其 结果 ， 
默认 值 为 “/”。 


rabbitmqctl list queues [-p vhost] [queueinfoitem ...] 
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此 命令 返回 队列 的 详细 信息 ， 如 果 无 [-p vhost] 参 数 ， 将 显示 默认 的 vhost 为 “/” 中 的 
队列 详情 。queueinfoitem 参数 用 于 指示 哪些 队列 的 信息 项 会 包含 在 结果 集中 ， 结 果 集 的 列 
顺序 将 匹配 参数 的 顺序 。queueinfoitem 可 以 是 下 面 列表 中 的 任何 值 。 


E 
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$ 


name: 队列 名 称 。 

durable: 队列 是 否 持久 化 。 

auto_delete: 队列 是 否 自动 删除 。 

arguments: 队列 的 参数 。 

policy: 应 用 到 队列 上 的 策略 名 称 。 

pid: 队列 关联 的 Erlang 进程 的 ID。 

owner pid: 处 理 排他 队列 连接 的 Erlang 进程 ID. 如 果 此 队列 是 非 排 他 的 ,此 值 将 为 空 。 
exclusive: 队列 是 否 是 排他 的 。 


exclusive consumer pid: 订阅 到 此 排他 队列 的 消费 者 相关 的 信道 关联 的 Erlang 
进程 ID。 如果 此 队列 是 非 排他 的 ， 此 值 将 为 空 。 


exclusive consumer tag: 订阅 到 此 排他 队列 的 消费 者 的 consumerTag。 如 果 
此 队列 是 非 排他 的 ， 此 值 将 为 空 。 


messages ready: 准备 发 送 给 客户 端的 消息 个 数 。 

messages unacknowledged: 发 送 给 客户 端 但 尚未 应 答 的 消息 个 数 。 
messages: 准备 发 送 给 客户 端 和 未 应 答 消息 的 总 和 。 

messages ready ram: 驻 留 在 内 存 中 messages_ready 的 消息 个 数 。 


messages unacknowledged ram: 驻 留 在 内 存 中 messages unacknowledged 
的 消 息 个 数 。 


messages ram: 驻 留 在 内 存 中 的 消息 总 数 。 


* messages persistent: 队列 中 持久 化 消息 的 个 数 。 对 于 非 持久 化 队列 来 说 总 是 0。 
* messages bytes: 队列 中 所 有 消息 的 大 小 总 和 。 这 里 不 包括 消息 属性 或 者 任何 其 他 
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开销 。 

messages bytes ready: 准备 发 送 给 客户 端的 消息 的 大 小 总 和 。 
messages bytes unacknowledged: 发 送 给 客户 端 但 尚未 应 答 的 消息 的 大 小 总 和 。 
messages bytes ram: 驻 留 在 内 存 中 的 messages_bytes。 
messages bytes persistent: 队列 中 持久 化 的 messages_bytes。 

disk reads: 从 队列 启动 开始 ， 已 从 磁盘 中 读 取 该 队列 的 消息 总 次 数 。 

disk writes: 从 队列 启动 开始 ， 已 向 磁盘 队列 写 消息 的 总 次 数 。 

consumer: 消费 者 数目 。 


consumer_utilisation: 队列 中 的 消息 能 够 立刻 投递 给 消费 者 的 比率 , 介 于 0 和 1 
之 间 。 这 个 受 网 络 拥塞 或 者 Basic.Qos 的 影响 而 小 于 1。 


memory: 与 队列 相关 的 Erlang 进程 所 消耗 的 内 存 字 节 数 ， 包 括 栈 、 堆 及 内 部 结构 。 
* slave pids: 如 果 队 列 是 镜像 的 ， 列 出 所 有 slave 镜像 的 Pid。 


信 synchronised slave pids: 如 果 队 列 是 镜像 的 ， 列 出 所 有 已 经 同步 的 slave 镜像 
的 pid. 
$ state: 队列 状态 。 正 常情 况 下 是 running: 如 果 队 列 正 常 同步 数据 可 能 会 有 


“{ syncing, MsgCount}” 的 状态 ; 如 果 队 列 所 在 的 节点 掉 线 了 ， 则 队列 显示 状态 为 
down〔 此 时 大 多 数 的 queueinfoitems 也 将 不 可 用 )。 


如 果 没 有 指定 queueinfoitems， 那 么 此 命令 将 显示 队列 的 名 称 和 消息 的 个 数 。 相 关 示 
例如 下 : 


[root@nodel ~]# rabbitmqctl list queues name durable auto delete arguments -q 
queuel true false [] 
queue2 true false  [] 
queue3 true false [] 
[root@nodel ~]# rabbitmqctl list queues name messages messages ram 
messages persistent 
Listing queues ... 
queue10 0 0 
queue2 0 0 0 
queue3 1 i 2D 
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[root@nodel ~]# rabbitmqctl list queues -p vhostl name disk writes disk reads -q 


queue4 3390 0 
queue5 0 0 


rabbitmqctl list exchanges [-p vhost] [exchangeinfoitem ...] 


返回 交换 器 的 详细 细节 ， 如 果 无 [-p vhost] 参 数 ， 将 显示 默认 的 vhost 为 “/” 中 的 交换 
器 详情 。exchangeinfoitem 参数 用 于 指示 哪些 信息 项 会 包含 在 结果 集中 ， 结 果 集 的 列 顺序 
将 匹配 参数 的 顺序 。exchangeinfoitem 可 以 是 下 面 列 表 中 的 任何 值 。 


$ name: 交换 器 的 名 称 。 
$ type: 交换 器 的 类 型 。 


$ durable: 设置 是 否 持久 化 。dqurable 设置 为 true 表示 持久 化 ， 反 之 是 非 持 久 化 。 持 
久 化 可 以 将 交换 器 信息 存盘 ， 而 在 服务 器 重启 的 时 候 不 会 丢失 相关 信息 。 


auto_delete: 设置 是 否 自动 删除 。 
internal: 是 否 是 内 置 的 。 


分 9 9 9 


arguments: 其 他 一 些 结构 化 参数 ， 比 如 alternate-exchange。 


policy: 应 用 到 交换 器 上 的 策略 名 称 。 


exchangeinfoitem 的 内 容 和 客户 端 中 的 channel.exchangeDeclare 方法 的 参数 基 
本 一 致 ， 具 体内 容 可 以 参考 3.2.1 节 。 如 果 没 有 指定 exchangeinfoitem， 那 么 此 命令 将 显示 


交换 器 的 名 称 和 类 型 。 相 关 示 例如 下 : 


[root@nodel ~]# rabbitmqctl list exchanges name type durable auto delete internal 


arguments policy -q 


amq.rabbitmq.trace topic true 
amq.headers headers true 

direct true 
amq.match headers true 
amq.topic topic true 
amq.fanout fanout true 
amq.rabbitmq.log topic true 
amq.direct direct true 


rabbitmqctl list bindings [-p vhost] [bindinginfoitem .. 


false 
false 
false 
false 
false 
false 
false 
false 


true [] 
false [] 
false [] 
false  [] 
false [] 
false [] 
true [] 
false [] 


] 


返回 绑 定 关系 的 细节 ， 如 果 无 [-p vhost] 参 数 ， 将 显示 默认 的 vhost 为 “/” 中 的 绑 定 关 
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系 详情 。bindinginfoitem 人 参数 用 于 指示 哪些 信息 项 会 包含 在 结果 集中 ， 结 果 集 的 列 顺序 将 
匹配 参数 的 顺序 。bindinginfoitem 可 以 是 下 面 列表 中 的 任何 值 。 


* source name: 绑 定 中 消息 来 源 的 名 称 。 

+ source kind: 绑 定 中 消息 来 源 的 类 别 。 

* destination name: 绑 定 中 消息 目的 地 的 名 称 。 
信 destination kind: 绑 定 中 消息 目的 地 的 种 类 。 
* routing key: 绑 定 的 路 由 键 。 

信 arguments: 绑 定 的 参数 。 


如 果 没 有 指定 bindinginfoitem， 那 么 将 显示 所 有 的 条 目 。 相 关 示 例如 下 : 


[root@nodel ~]# rabbitmqctl list bindings -q 
exchange  queuel queue queuel [] 
exchange queue2 queue queue2 [] 

exchangel exchange  queuel queue rki [1 


其 中 ， 交 换 器 exchangel 和 队列 queuel 通过 rkl 进行 绑 定 ， 还 有 一 个 独立 的 队列 queue2. 
显示 的 第 一 行 是 默认 的 交换 器 与 queuel 进行 绑 定 ， 这 个 是 RabbitMQ 内 置 的 功能 。 


rabbitmqctl list connections [connectioninfoitem ...] 


返回 TCP/IP 连接 的 统计 信息 。connectioninfoitenm 参数 用 于 指示 哪些 信息 项 会 包含 在 
结果 集中 ， 结 果 集 的 列 顺序 将 匹配 参数 的 顺序 。connectioninfoitem 可 以 是 下 面 列表 中 的 


任何 值 。 

* pid: 与 连接 相关 的 Erlang 进程 ID. 

+ name: 连接 的 名 称 。 

* port: 服务 器 端口 。 

令 host: 返回 反 向 DNS 获取 的 服务 器 主机 名 称 ， 或 者 IP 地 址 ， 或 者 未 启用 。 
+ 


peer port: 服务 器 对 端 端口 。 当 一 个 客户 端 与 服务 器 连接 时 ， 这 个 客户 端的 端口 就 
是 peer port. 


* peer host: 返回 反 向 DNS 获取 的 对 端 主机 名 称 ， 或 者 IP 地 址 ， 或 者 未 启用 。 
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ssl: 是 否 启用 SSL. 

ssl protocol: SSL 协议 ， 如 tlsv1。 

ssl key exchange: SSL 密 钥 交 换算 法 ， 如 rsa。 

ssl cipher: SSL 加 密 算法 ， 如 aes_256_cbc。 

ssl hash: SSL 哈 希 算法 ， 如 sha。 

peer cert subject: 对 端的 SSL 安全 证 书 的 主题 ， 基 于 RFC4514 的 形式 。 

peer cert issuer: 对 端 SSL 安全 证 书 的 发 行者 ， 基 于 RFC4514 的 形式 。 

peer cert validity: 对 端 SSL 安全 证 书 的 有 效 期 。 

state: 连接 状态 , 包括 starting. tuning.opening.running. flow,blocking. 
blocked. closing 和 closed 这 几 种 。 


channels: 该 连接 中 的 信道 个 数 。 


protocol: 使 用 的 AMQP 协议 的 版 本 ， 当 前 是 {0,9,1} 或 者 {0,8,0}。 注 意 ， 如 果 客 户 
端 请 求 的 是 AMQP 0-9 的 连接 ，RabbitMQ 也 会 将 其 视 为 0-9-1。 


auth mechanism: 使 用 的 SASL 认证 机 制 ， 如 PLAIN, AMQPLAIN, EXTERNAL, 
RABBIT-CR-DEMO 等 。 


user: 与 连接 相关 的 用 户 名 。 

vhost: 与 连接 相关 的 vhost 的 名 称 。 

timeout: 连接 超时 /协商 的 心跳 间隔 ， 单 位 为 秒 。 

frame max: 最 大 传输 帧 的 大 小 ， 单 位 为 B。 

channel max: 此 连接 上 信道 的 最 大 数量 。 如 果 值 0， 则 表示 无 上 限 ， 但 客户 端 一 般 
会 将 0 转变 为 65535。 

client properties: 在 建立 连接 期 间 由 客户 端 发 送 的 信息 属性 。 

recv_oct: 收 到 的 字 节 数 。 

recv_cnt: 收 到 的 数据 包 个 数 。 
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send oct: 发 送 的 字 节 数 。 

send cnt: 发 送 的 数据 包 个 数 。 
send pend: 发 送 队列 大 小 。 
connected at: 连接 建立 的 时 间 戳 。 


如 果 没 有 指定 connectioninfoitem， 那 么 会 显示 user. peer host. peer port 
和 state 这 几 项 信息 。 相 关 示 例如 下 : 


[root@nodel ~]# rabbitmqctl list connections user peer host peer port state -q 
root 192.168.0.22 57304 running 

root 192.168.0.22 57316. running 

[root(nodel ~]# rabbitmqctl list connections -q 

root 192.168.0.22 57304 running 

root 192.168.0.22 57316 running 

[root(nodel ~]# rabbitmqctl list connections pid name host -q 
«rabbit8(nodel.1.623.0»  192.168.0.22:57304 -> 192.168.0.2:5672 192.168.0.2 
«rabbitünodel.1.635.0»  192.168.0.22:57316 > 192.168,0.2:5672 192.168.0.2 


rabbitmqctl list channels [channelinfoitem ...] 


返回 当前 所 有 信道 的 信息 。channelinfoitem 参数 用 于 指示 哪些 信息 项 会 包含 在 结果 集 
中 ， 结 果 集 的 列 顺序 将 匹配 参数 的 顺序 。channelinfoitem 可 以 是 下 面 列表 中 的 任何 值 。 


个 
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pid: 与 连接 相关 的 Erlang 进程 ID。 

connection: 信道 所 属 连接 的 Erlang 进程 ID。 

name: 信道 的 名 称 。 

number: 信道 的 序号 。 

user: 与 信道 相关 的 用 户 名 称 。 

vhost: 与 信道 相关 的 vhost。 

transactional: 信道 是 否 处 于 事务 模式 。 

confirm: 信道 是 否 处 于 publisher confirm 模式 。 

consumer count: 信道 中 的 消费 者 的 个 数 。 

messages unacknowledged: 已 投递 但 是 还 未 被 ack 的 消息 个 数 。 
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* messages uncommitted: 已 接收 但 是 还 未 提交 事务 的 消息 个 数 。 
* acks uncommitted: E ack 收 到 但 是 还 未 提交 事务 的 消息 个 数 。 


$ messages unconfirmed: 已 发 送 但 是 还 未 确认 的 消息 个 数 。 如 果 信 道 不 处 于 
publisher confirm 模式 下 ， 则 此 值 为 0。 


* perfetch count: 新 消费 者 的 Qos 个 数 限 制 。0 表示 无 上 限 。 
* global prefetch count: 整个 信道 的 Qos 个 数 限制 。0 表示 无 上 限 。 


如 果 没 有 指定 channelinfoitem， 那 么 会 显示 pid. user. consumer count 和 
messages_unacknowledged 这 几 项 信息 。 相 关 示 例如 下 : 


[root(nodel ~]# rabbitmqctl list channels -q 
X«rabbit8nodel.1.631.0» root 0 g 

X«rabbit8nodel.1.643.0» root Ki 0 

[root(nodel ~]# rabbitmqctl list channels pid connection -q 
«rabbit8nodel.1.631.0»  «rabbitG8nodel.1.623.0» 
«rabbit8nodel.1.643.0»  «rabbitG8nodel.1.635.0» 


rabbitmqctl list consumers [-p vhost] 
列举 消费 者 信息 。 每 行将 显示 由 制 表 符 分 隔 的 已 订阅 队列 的 名 称 、 相 关 信 道 的 进程 标识 、 
consumerTag、 是 否 需 要 消费 端 确认 、prefetch_count 及 参数 列表 这 些 信息 。 相 关 示 例如 下 : 


[root@nodel ~]# rabbitmqctl list consumers -p default -q 
queue4 «rabbit8nodel.1.1628.11» consumer zzh true © [I 


rabbitmqctl status 


显示 Broker 的 状态 ， 比 如 当前 Erlang 节点 上 运行 的 应 用 程序 、RabbitMQ/Erlang 的 版 本 信 
息 、OS 的 名 称 、 内 存 及 文件 描述 符 等 统计 信息 。 具 体 示例 可 以 参考 1.4.3 节 。 


rabbitmqctl node health check 


对 RabbitMQ 节点 进行 健康 检查 , 确认 应 用 是 否 正常 运行 .List_queues füllist channels 
是 否 能 够 正常 返回 等 。 相 关 示 例如 下 : 


[rootQnodel ~]# rabbitmqctl node health check 
Timeout: 70.0 seconds 

Checking health of node rabbit(nodel 

Health check passed 
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rabbitmqctl environment 

显示 每 个 运行 程序 环境 中 每 个 变量 的 名 称 和 值 。 

rabbitmqctl report 

为 所 有 服务 器 状态 生成 一 个 服务 器 状态 报告 , 并 将 输出 重 定 向 到 一 个 文件 ,相关 示例 如 下 : 


[root@nodel ~]# rabbitmqctl report > report.txt 
rabbitmqctl eval {expr} 


执行 任意 Erlang 表达 式 。 相 关 示 例如 下 (示例 命令 用 于 返回 rabbitmqct1l 连接 的 节点 名 称 ): 


[root@nodel ~]# rabbitmqctl eval 'node().' 
rabbit8nodel 


eval 的 扩展 


用 户 、Parameter、vhost、 权 限 等 都 可 以 通过 rabbitmqctl 工具 来 完成 创建 (或 删除 ) 的 
操作 ， 反 观 交换 器 、 队 列 及 绑 定 关系 的 创建 〈 或 删除 ) 操作 并 无 相应 的 rabbitmqctl 工具 类 
的 命令 ， 到 目前 为 止 介绍 的 只 有 通过 客户 端 或 者 Web 管理 界面 来 完成 ， 这 对 于 CLI' 的 使 用 爱 
好 者 来 说 无 疑 是 一 种 遗憾 。 


这 里 就 展示 如 何 通 过 rabbitmqctl eval {expr} 以 “曲线 救国 ”的 形式 实现 通过 
rabbitmqctl 工具 来 创建 交换 器 、 队 列 及 绑 定 关系 。 执 行 下 面 三 条 命令 就 可 以 创建 一 个 交换 
器 exchange2、 一 个 队列 queue2 并 通过 绑 定 键 rk2 进行 绑 定 。 


rabbitmqctl eval 'rabbit exchange:declare([(resource,««"/"»»,exchange,««"excha 
nge2"»»),direct,true,false,false,[]l).' 


rabbitmqctl eval 'rabbit amqqueue:declare((resource,««"/"»»,queue,««"queue2"»5], 
true,false,[],none).' 


rabbitmqctl eval 'rabbit binding:add((binding,(resource,««"/"»»,exchange, 
««"exchange2"»»5],««"rk2"»», (resource,««"/"»»,queue,««"queue2"»»]), [])).' 


其 实 这 里 是 调用 了 Erlang 中 对 应 模块 的 相应 函数 , 语法 类 似 “Module:Function (Arg).". 





! CLI (command-line interface， 命 令 行 界 面 ) 是 指 可 在 用 户 提示 符 下 键入 可 执行 指令 的 界面 ， 它 通常 不 支持 鼠标 ， 用 户 通过 键 
盘 输入 指令 ， 计 算 机 接收 到 指令 后 ， 予 以 执行 。 
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对 于 交换 器 的 创建 ， 则 调用 了 rabbit exchange 模块 的 declare 函数 ， 该 函数 具体 声 
明 为 : 


declare (XName, Type, Durable, AutoDelete, Internal, Args). 


不 同 的 RabbitMQ 版 本 参数 会 略 有 差异 ， 比 如 高 版 本 会 多 个 Username 参数 ， 采 用 上 面 的 
定义 可 以 在 多 个 当前 主流 版 本 中 创建 交换 器 。 对 应 的 参数 如 下 所 述 。 


 XName: 交换 器 的 命名 细节 ， 具体 格式 为 {resource, VHost, exchange, Name}。 
VHost 为 虚拟 主机 的 名 称 , Name 为 交换 器 的 名 称 。 注 意 VHost 和 Name 需要 以 “<<>>” 
aR, ENX binary 类 型 。 


€ Type: 交换 器 的 类 型 ， 可 选 值 为 direct, headers. topic 和 fanout。 

$9 Durable: 是 否 需要 持久 化 。 

* AutoDelete: 是 否 自动 删除 。 

* Internal: 是 否 是 内 置 的 交换 器 。 

* args: 交换 器 的 其 他 选项 参数 ， 一 般 设 置 为 [] 。 

与 创建 交换 器 对 应 的 删除 操作 为 调用 rabbit_exchange 模 块 的 delete 函数 ,示例 如 下 : 


[root@nodel ~]# rabbitmqctl eval 'rabbit exchange:delete({resource,<<"/">>, 
exchange,««"exchange2"»»],false).' 
ok 


对 于 队列 的 创建 , 则 调用 了 rabbit amqqueue 模块 的 declare 函数 , 该 函数 具体 声明 为 ; 


declare(QueueName, Durable, AutoDelete, Args, Owner). 


不 同 的 RabbitMQ 版 本 参数 会 略 有 差异 ， 比 如 高 版 本 会 多 一 个 ActingUser 参数 ， 采 用 上 
面 的 定义 可 以 在 多 个 当前 主流 版 本 中 创建 交换 器 。 对 应 的 参数 如 下 所 述 。 


+ QueueName: 队列 的 命名 细节 ， 具体 格式 为 (resource, VHost, queue, Name). 
VHost 为 虚拟 主机 的 名 称 , Name 为 交换 器 的 名 称 。 注 意 VHost Hl Name 需要 以 *<<>>” 
AR, PREX binary 类 型 。 


$ Durable: 是 否 需要 持久 化 。 
+ AutoDelete: 是 否 自动 删除 。 
* args: 队列 的 其 他 选项 参数 ， 一 般 设置 为 [] 。 
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* Owner: 用 于 队列 的 独占 模式 ， 一 般 设置 为 none。 


与 创建 队列 对 应 的 删除 操作 为 调用 rabbit amqqueue BER internal delete 函数 ， 
示例 如 下 : 


[root8nodel ~]# rabbitmqctl eval 
'rabbit amqqueue:internal delete((resource,««"/"»»,queue,««"queue2"»»5]).' 
ok 


对 于 绑 定 关 系 的 创建 , 则 调用 了 rabbit binding 模块 的 aqdd 函数, 该 函数 具体 声明 为 : 
add (Binding) 
不 同 的 RabbitMQ 版 本 参数 会 略 有 差异 ， 比 如 高 版 本 会 多 一 个 ActingUser 参数 ， 采 用 上 
面 的 定义 可 以 在 多 个 当前 主流 版 本 中 创建 交换 器 。 对 应 的 参数 如 下 所 述 。 
信 Binding: HERA, 可 以 是 exchange 到 exchange， 也 可 以 是 exchange 到 queue. 
RIKI (binding, Source, Key, Destination, Args}» Source 表示 消息 
源 ， 必 须 为 交换 器 ， 格 式 为 {resource，VHost，exchange，Name}。Key 表示 路 由 


$E. Destination 为 目的 端 ， 格 式 为 {resource，VHost，exchange，XName } 或 者 
(resource, VHost, queue, QName). Args 为 其 他 选项 参数 ， 一 般 设 置 为 []。 


与 创建 绑 定 关系 对 应 的 解 绑 操作 为 调用 rabbit binding 模块 的 remove 函数 ,示例 如 下 : 


[root@nodel ~]# rabbitmqctl eval 

'rabbit binding:remove ((binding, (resource,««"/"»»,exchange, ««"exchange2"»»], 
««"rk2"»»,(resource,««"/"»»,queue,««"queue2"»»5]), []]).' 

ok 


小 窑 门 : 
若 要 删除 所 有 的 交换 器 、 队 列 及 绑 定 关 系 ， 删 除 对 应 的 vhost 就 可 以 “一 键 搞定 ”， 而 不 需 
要 一 个 个 遍历 删除 。 


5.6 HTTP API 接口 管理 


RabbitMQ Management 插件 不 仅 提供 了 Web 管理 界面 ， 还 提供 了 HTTP API 接口 来 方便 调 
Fi. 比如 创建 一 个 队列 , 就 可 以 通过 PUT 方法 调用 /api/queues/vhost/name 接口 来 实现 。 
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下 面 的 示例 通过 curl 命令 调用 接口 来 完成 队列 queue 的 创建 : 


[rootànodel ~]# curl -i -u root:root123 -H "content-type:application/json" 
-XPUT -d '("auto delete":false,"durable":true,""node":"rabbitQG8node2"]' 
http://192.168.0.2:15672/api/queues/$2F/queue 


HTTP/1.1 201 Created 

server: Cowboy 

date: Fri, 25 Aug 2017 06:03:17 GMT 
content-length: 0 

content-type: application/json 

vary: accept, accept-encoding, origin 


注意 上 面 命令 中 的 “%2F” 是 指 默认 的 vhost， 即 “/”， 这 类 特殊 字符 在 HTTP URL 中 是 需 
要 转 义 的 。 这 里 的 cur1? 命 令 又 为 创建 (或 删除 ) 交换 器 、 队 列 及 绑 定 关系 提供 了 另 一 种 CLI 
的 实现 方式 .所 有 的 HITPAPI 接 口 都 需要 HTTP 基础 认证 (使 用 标准 的 RabbitMQ 用 户 数据 库 )， 
默认 的 是 guest/guest〈 非 localhost 的 不 能 使 用 这 组 认证 ， 除 非特 殊 设 置 )。 


这 里 的 HTTP API 是 完全 基于 RESTful 风格 的 , 不同 的 HTTP API 接口 所 对 应 的 HTTP 方法 
各 不 相同 ， 这 里 一 共 涉 及 4 种 HTTP 方法 : GET、PUT、DELETE 和 POST。GET 方法 一 般 用 
来 获取 如 集群 、 节 点 、 队 列 、 交 换 器 等 信息 。PUT 方法 用 来 创建 资源 ， 如 交换 器 、 队 列 之 类 的 。 
DELETE 方法 用 来 删除 资源 。POST 方法 也 是 用 来 创建 资源 的 ， 与 PUT 不 同 的 是 ，POST 创建 
的 是 无 法 用 具体 名 称 的 资源 。 比 如 绑 定 关 系 (bindings) 和 发 布 消息 (publish) 无 法 指定 一 个 具 
体 的 名 称 。 


下 面 示例 展示 了 通过 GET 方法 来 获取 之 前 创建 的 队列 queue 的 信息 : 


[root@nodel ~]# curl -i -u root:rootl123 -XGET 
http://192.168.0.2:15672/api/queues/$2F/queue 


HTTP/1.1 200 OK 

server: Cowboy 

date: Fri, 25 Aug 2017 08:20:22 GMT 

content-length: 1275 

content-type: application/json 

vary: accept, accept-encoding, origin 

Cache-Control: no-cache 

("consumer details":[],"incoming":[],"deliveries":[],"messages details":("ra 
te":0.0),"messages":0,"messages unacknowledged details":... (省略 若 干 信息 ) } 


? curl 是 利用 URL 语法 在 命令 行 方式 下 工作 的 开源 文件 传输 工具 。 它 被 广泛 应 用 在 UNIX、 多 种 Linux 发 行 版 中 ， 并 且 有 DOS 
和 Win32、Win64 下 的 移植 版 本 。 
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对 应 的 删除 为 : 
[root@nodel ~]# curl -i -u root:root123 -XDELETE http://192.168.0.2:15672/api/ 
queues/$2F/queue 


HTTP/1.1 204 No Content 

server: Cowboy 

date: Fri, 25 Aug 2017 08:36:40 GMT 
content-length: 0 

content-type: application/json 

vary: accept, accept-encoding, origin 


K 5-2 展示 了 当前 最 新 版 本 的 HTTP API 接口 列表 ， 以 及 对 应 的 HTTP 方法 。 每 个 版 本 的 
HTTP API 接口 有 可 能 略 有 差异 ， 点 击 Web 管理 界面 (可 参考 图 5-5) 左下 角 的 “HTTP API” 
即 可 跳 转 到 相应 的 “RabbitMQ Management HTTP API” 帮 助 页 面 ， 里 面 有 详细 的 接口 信息 。 


表 5-2 HTTP API 接口 列表 


/api/overview 
描述 整个 系统 的 各 种 信息 


/api/cluster-name 


集群 的 名 称 


/api/nodes 
集群 中 节点 的 信息 。 示 例 内 容 可 以 参考 附录 B 


/api/nodes/name 
集群 中 单个 节点 的 信息 


/api/extensions 


管理 插件 的 扩展 列表 


/api/definitions 

GET 方法 列 出 集群 中 所 有 的 元 数据 信息 ， 包 括 交换 器 、 队 列 、 绑 定 关 系 、 用 户 、vhost、 
权限 及 参数 。POST 方法 用 来 加 载 新 的 元 数据 信息 ， 不 过 需要 注意 如 下 内 容 : 

(1) 新 的 原 数据 信息 会 与 原本 的 合并 ， 如 果 旧 的 元 数据 信息 中 某 些 项 在 新 加 载 的 
元 数据 中 没有 定义 ， 则 不 受 任何 影响 

(2) 对 于 交换 器 、 队 列 及 绑 定 关系 等 不 可 变 的 内 容 ， 如 果 新 旧 元 数据 有 冲突 ， 则 
会 报错 

(3) 对 于 其 他 的 可 变 的 内 容 ， 如 果 新 旧 元 数据 有 冲突 ， 则 新 的 会 替换 旧 的 

(4) 如 果 在 加 载 过 程 中 发 生 错误 ， 加 载 过 程 会 停止 ， 最 终 只 能 加 载 到 部 分 新 的 元 
数据 信息 

在 7.4.1 节 中 有 更 详细 的 介绍 。 示 例 内 容 可 以 参考 附录 A 
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续 表 


/api/definitions/vhost 
RE 接口 细 化 到 vhost 级 别 ， 其 余 内 容 同 上 


ÜBEN — n 
所 有 的 连接 信息 
KLI D EMO 
指定 的 vhost 中 所 有 连接 信息 
a A /api/connections/name 
GET 方法 列 出 指定 连接 的 信息 。DELETE 方法 可 以 close 指定 的 连接 
PILGRA ED — — UNSER: 
指定 连接 的 所 有 信道 信息 
FIN GR Uo HMMDEN ONLY 
所 有 信道 的 信息 
IE uud 
指定 的 vhost 中 所 有 信道 信息 
Pme SM /api/channels/channel 
指定 的 信道 信息 
LB EN R— 
所 有 的 消费 者 信息 


/api/consumers/vhost 


指定 vhost 中 的 所 有 消费 者 信息 


























/api/exchanges 


所 有 交换 器 信息 


a E 
指定 vhost 中 所 有 交换 器 信息 

/api/exchanges/vhost/name 

GET 方法 列 出 一 个 指定 的 交换 器 信息 。PUT 方法 可 以 声明 一 个 交换 器 ， 对 应 的 内 
容 可 以 参考 如 下 : 
{"type":"direct","auto_delete":false,"durable":true,"internal":false,"arguments":{}} 

其 中 type 是 必需 的 ， 其 他 都 是 可 选 的 。DELETE 方法 可 以 删除 指定 的 交换 器 ， 其 
中 可 以 添加 if-unused-true 参数 用 来 防止 有 队列 与 其 绑 定时 能 够 被 删除 
/api/exchanges/vhost/name/bindings/source 


列 出 指定 交换 器 的 所 有 绑 定 关系 ， 此 交换 器 需 为 绑 定 关 系 的 源 端 


/api/exchanges/vhost/name/bindings/destination 
列 出 指定 交换 器 的 所 有 绑 定 关 系 ， 此 交换 器 需 为 绑 定 关系 的 目的 端 
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续 表 


/api/exchanges/vhost/name/publish 
向 指定 的 交换 器 中 发 送 一 条 消息 ， 对 应 的 内 容 可 以 参考 : 
"properties": (), "routing key":"my key", "payload";"my body", 

X "payload encoding":"string"] 
这 里 所 有 的 项 都 是 必需 的 ， 如 果 发 送 成 功 ， 则 会 返回 : ("routed": true}。 这 个 接口 
不 适合 做 稳定 、 高 效 的 发 送 之 用 ， 可 以 采用 其 他 的 方式 比如 通过 AMQP 协议 或 者 
其 他 长 连接 的 协议 


| 

列 出 所 有 的 队列 信息 

DERRE- 7 NN 
列 出 指定 的 vhost 下 所 有 的 队列 信息 


/api/queues/vhost/name 
GET 方法 列 出 执行 的 队列 信息 。PUT 方法 可 以 声明 一 个 队列 ， 对 应 的 内 容 可 以 参 
E 

X X X 
f"auto delete":false,"durable":true," arguments": {},"node":"rabbit@smacmullen"} 
其 中 所 有 的 项 都 是 可 选 的 。DELETE 方法 用 来 删除 一 个 队列 ， 当 然 可 以 指定 
if-empty 或 者 让 unused 参数 


下 一 一 

列 出 指定 队列 的 所 有 绑 定 关系 

EEIN o 
清空 (purge) 指定 的 队列 


/api/queues/vhost/name/actions 

对 指定 的 队列 附加 一 些 动作 ， 对 应 的 内 容 可 以 参考 ; 

f"action";"sync"j 

目前 仅 支持 sync 和 cancel. sync 

/api/queues/vhost/name/get 

从 指定 队列 中 获取 消息 ， 对 应 的 内 容 可 以 参考 ; 

("count":5,"requeue":true, "encoding":"auto", "truncate":50000] 

count 表示 最 大 能 获取 的 消息 个 数 ， 实 际 可 能 小 于 这 个 值 ，requeue 表示 获取 到 这 
些 消息 时 是 否 从 队列 中 删除 ， 如 果 requeue 为 tue， 则 消息 不 会 被 删除 ， 但 是 消息 
的 redelivered 标示 会 被 设置 ，encoding 表示 编码 格式 ， 两 种 取 值 : auto 和 base64， 
auto 指 如 果 消 息 符合 UTF-8 格式 则 返回 string 类 型 ， 否 则 为 base64 类 型 ， truncate 
表示 如 果 消 息 的 payload 超过 指定 大 小 则 会 被 截断 。 除 了 truncate， 其 余 项 都 是 必 
需 的 。 注 意 这 个 接口 是 用 来 做 测试 用 的 ， 如 果 要 持续 的 消费 队列 的 消息 ， 需 要 采 


g /api/bindings 
列 出 所 有 绑 定 关系 的 信息 
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续 表 


/api/bindings/vhost 
列 出 指定 的 vhost 中 所 有 绑 定 关系 的 信息 


/api/bindings/vhost/e/exchange/q/queue 

GET 方法 列 出 一 个 指定 的 交换 器 和 一 个 指定 的 队列 中 的 所 有 绑 定 关系 的 信息 。 注 
意 一 个 交换 器 和 一 个 队列 之 间 可 以 绑 定 多 次 。POST 用 来 添加 绑 定 关系 ， 对 应 的 内 
容 可 以 参考 ; 

f"routing key":"my routing key", "arguments": {}} 

其 中 所 有 的 项 都 是 可 选 的 


lapi/bindings/vhost/e/exchange/q/queuelprops 

GET 方法 列 出 一 个 交换 器 和 一 个 队列 的 一 个 单独 的 绑 定 关系 的 信息 DELETE 方法 
用 来 解 绑 相应 的 绑 定 关系 ， 其 中 props 表示 的 是 /api/bindings 返回 的 绑 定 关 系列 表 
里 的 properties key 的 值 ， 具 体 是 指 绑 定时 routingkey 与 arguments 的 哈 希 值 的 组 
合 ， 一 般 arguments 为 空 ， 此 时 properties_key 等 于 routingkey 


/api/bindings/vhost/e/source/e/destination 

GET 方法 用 来 列 出 两 个 交换 器 的 所 有 绑 定 关系 的 信息 ，POST 方法 用 来 添加 绑 定 
关系 ， 与 接口 /api/bindings/vhost/e/exchange/q/queue 相似 
/api/bindings/vhost/e/source/e/destination/props 

与 接口 /api/bindings/vhost/e/exchange/q/queue/props 相似 , 只 不 过 是 两 个 交换 器 之 间 


/api/vhosts/name 

GET 方法 列 出 指定 vhost 的 信息 。PUT 方法 用 来 添加 一 个 vhost，host 通常 只 有 一 
个 名 字 ， 所 以 不 需要 任何 内 容 以 做 请 求 之 用 。DELETE 方法 用 来 删除 一 个 vhost 
/api/vhosts/name/permissions 

列 出 指定 vhost 的 所 有 权限 信息 

/api/users 

列 出 所 有 的 用 户 信息 

/api/users/name 

GET 方法 列 出 指定 的 用 户 信息 。POST 方法 用 来 添加 一 个 用 户 ， 对 应 的 内 容 参考 ; 


("password":"secret", "tags":"administrator"] 


f"password hash":"21moth814HOD ViLaK9Fxi619ds8-", "tags":"administrator"] 

其 中 tags 是 必需 的 , 用 来 标识 用 户 角色 ,详细 内 容 可 以 参考 5.2 节 。 对 于 password 
或 者 password hash 而 言 ， 两 者 可 以 择 其 一 。 如 果 password hash 为 “”， 则 用 户 可 
以 无 密码 登录 。DELETE 方法 用 来 删除 指定 的 用 户 
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续 表 
PB - c ONNNENN 
用 来 获取 指定 用 户 的 所 有 权限 
FREI 一再 
显示 当前 的 登录 用 户 
-LI-I Ee — 
列 出 所 有 用 户 的 所 有 权限 
/api/permissions/vhost/user 
GET 方法 列 出 指定 的 权限 。PUT 方法 添加 指定 的 权限 ， 对 应 的 内 容 参 考 ; 
("configure":".*","write":".*" "read":".*"} 


所 有 项 都 是 必需 的 ， 对 应 configure. write. read 的 细节 可 以 参考 5.1 45. DELETE 
方法 用 来 删除 指定 的 权限 


/api/parameters 


iind vhost 级 别 的 Parameter. 4j Parameter 的 更 多 细节 可 以 参考 6.3 节 的 内 


列 出 指定 组 件 (比如 federation-upstream、shovel 等 ) 的 所 有 vhost 级 别 的 Parameter 
rim Bd —— ———- 
列 出 指定 vhost 和 组 件 的 所 有 vhost 级 别 的 Parameter 


/api/parameters/component/vhost/name 
GET 方法 列 出 一 个 指定 的 vhost 级 别 的 Parameter. PUT. 方法 用 来 设置 一 个 
DE E Parameter， 对 应 的 内 容 参 考 如 下 : 
("vhost": "/", "component":"federation", "name":"local username", "value": "guest"} 
DELETE 方法 用 来 删除 一 个 指定 的 vhost 级 别 的 Parameter 
iM MM Uf Seer 
列 出 所 有 的 global 级 别 的 Parameter 


/api/global-parameters/name 

GET 方法 列 出 一 个 指定 的 global 级 别 的 Parameter. PUT 方法 用 来 设置 一 个 指定 的 
X X 又 global 级 别 的 Parameter， 对 应 的 内 容 参 考 : 

{"name":"user_vhost_mapping","value":{"guest":"/","rabbit":"warren"}} 

DELETE 方法 用 来 删除 一 个 指定 的 global 级 别 的 Parameter 


P EE E E RN 

列 出 所 有 的 Policy。 有 关 Policy 的 所 有 细节 可 以 参考 6.3 节 

BID —7 
列 出 指定 vhost 下 的 所 有 Policy 
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续 表 


/api/policies/vhost/name 
GET 方法 列 出 指定 的 Policy. PUT 方法 用 来 设置 一 个 Policy， 对 应 的 内 容 可 以 参 


Íf"pattern";"^amq.", "definition": — ("federation-upstream-set":"all"], ^ "priority":0, 
"apply-to": "all"? 
其 中 pattern 和 definition 是 必需 的 ， 其 余 可 选 。DELETE 方法 用 来 删除 一 个 指定 的 


/api/aliveness-test/vhost 

声明 一 个 队列 ， 并 基于 其 上 生产 和 消费 一 条 消息 ， 用 来 测试 系统 是 否 运行 完好 。 
这 个 接口 可 以 方便 一 些 监控 工具 〈 如 Zabbix) 的 调用 。 如 果 系 统 运行 完好 ， 调 用 
这 接口 会 返回 {status":"ok"}， 状 态 码 为 200。 更 多 内 容 可 以 参考 7.6.3 节 
/api/healthchecks/node 

对 当前 节点 中 进行 基本 的 健康 检查 ， 包 括 RabbitMQ 应 用 、 信 道 、 队 列 是 否 正常 运 
行 且 无 告警 。 如 果 一 切 正常 则 接口 返回 : 

("status";"ok" 

如 果 有 异常 则 接口 返回 : 

{"status":"failed","reason":"string"} 


不 管 正常 与 否 ， 状 态 都 是 200 


/api/healthchecks/node/node 
对 指定 节点 进行 基本 的 健康 检查 ， 其 余 同 /api/healthchecks/node 


HTTP API 接口 通常 用 来 方便 客户 端的 调用 ， 比 如 7.4.1 节 中 的 元 数据 创建 就 用 到 了 这 个 。 
如 果 单 纯 地 使 用 curl 的 方式 来 调用 ，rabbitmqadqmin 会 显得 更 加 方便 。rzabbitmaadmin 
也 是 RabbitMQ Management 插件 提供 的 功能 ， 它 会 包装 HTTP API 接口 ， 使 其 调用 显得 更 加 简 
洁 方便 。 比 如 前 面 的 创建 、 显 示 和 删除 队列 queue 就 可 以 这 么 做 : 


[root@nodel ~]# ./rabbitmqadmin -u root -p root123 declare queue name-queuel 
queue declared 
[root(nodel ~]# ./rabbitmqadmin list queues 








二 一 一 一 一 一 一 一 一 二 一 一 一 一 一 一 一 一 一 一 十 
name | messages | 

二 一 一 一 一 一 一 一 一 二 一 一 一 一 一 一 一 一 一 一 + 
queuel | 0 | 

二 一 一 一 一 一 一 一 一 二 一 一 一 一 一 一 一 一 一 一 十 


[root@nodel ~]# ./rabbitmqadmin -u root -p root123 delete queue name-queuel 
queue deleted 

[rootenodel ~]# ./rabbitmqgadmin list queues 

No items 
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rabbitmqadmin 是 需要 安装 的 ， 不 过 这 个 步骤 非常 简单 ， 可 以 点 击 Web 管理 页 面 左 下 角 
的 “Command Line” 跳 转 到 “rabbitmqadmin” 页 面 进 行 下载 ， 或 者 通过 下 面 的 示例 进行 下 载 。 


[root@nodel ~]# wget http://192.168.0.2:15672/cli/rabbitmqadmin 
--2017-08-25 17:32:50-- http://192.168.0.2:15672/cli/rabbitmqadmin 
Connecting to 192.168.0.2:15672... connected. 

HTTP request sent, awaiting response... 200 OK 

Length: 36192 (35K) [application/octet-stream] 

Saving to: "rabbitmqadmin" 

100% [ = ==== ===>] 36,192 --, -K/s in Os 
2017-08-25 17:32:50 (372 MB/s) - "rabbitmqadmin" saved [36192/36192] 
[root8nodel ~]# chmod +x rabbitmqadmin 


FÆ rabbitmqadmin 到 当前 目录 下 ,之 后 为 其 添加 可 执行 权限 ,在 使 用 rabbitmqadmin 
前 还 要 确保 已 经 成 功 安装 Python, Python 的 版 本 需 为 2.x。 下 面 的 示例 用 来 显示 当前 的 Python 
版 本 : 


[root@nodel ~]# python 

Python 2.6.6 (r266:84292, Jan 22 2014, 09:42:36) 

[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux2 

Type "help", "copyright", "credits" or "license" for more information. 
>>> quit() 


如 果 一 一 列举 rabbitmqadmin 的 用 法 未 免 过 于 兴 师 动 众 ， 可 以 通过 rabbitmqadmin 
--help 命令 来 获得 相应 的 使 用 方式 ， 参 考 如 下 : 


[root@nodel ~]# ./rabbitmqadmin --help 
Usage 








rabbitmqadmin [options] subcommand 
Options 


--help, -h show this help message and exit 
--config-CONFIG, -c CONFIG 
configuration file [default: -/.rabbitmqadmin.conf] 
--node-NODE, -N NODE node described in the configuration file [default: 
'default' only if configuration file is specified] 
--host-HOST, -H HOST connect to host HOST [default: localhost] 
--port-PORT, -P PORT connect to port PORT [default: 15672] 
--path-prefix-PATH PREFIX 
.... (省 略 若干 信息 ) 
More Help 


For more help use the help subcommand: 
rabbitmqadmin help subcommands # For a list of available subcommands 
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rabbitmqadmin help config # For help with the configuration file 


57 /JM&à 


本 章 的 内 容 主要 围绕 RabbitMQ 的 管理 这 个 主题 展开 ， 包 括 多 租户 、 权 限 、 用 户 、 应 用 和 
集群 管理 、 服 务 端 状态 等 方面 ， 这 些 都 可 以 通过 rabbitmqctl 这 一 系列 的 工具 来 管控 。 
rabbitmqctl 也 是 RabbitMQ 中 最 复杂 的 CU 管理 工具 ， 本 章 也 基本 涵盖 了 大 部 分 的 
rabbitmqctl 工具 的 使 用 细节 。 在 使 用 相关 命令 时 ， 完 全 可 以 把 本 章 的 内 容 作 为 一 个 使 用 手 
册 来 查阅 。 本 章 还 有 一 个 重点 就 是 rabbitmq management 插件 ， 它 在 提供 用 户 图 形 化 的 管 
理 功能 之 余 ， 还 提供 了 相应 的 监控 功能 。 不 仅 如 此 ， rabbitmq management 插件 还 提供 了 
HTTP API 接口 以 方便 用 户 调用 ， 比 如 在 后 面 7.4 节 和 7.5 节 中 所 讲 到 的 一 些 功能 都 需要 相关 的 
HTTPAPI 接口 的 协助 。 
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一 般 情况 下 , 可 以 使 用 默认 的 内 建 配置 来 有 效 地 运行 RabbitMQ,， 并 且 大 多 数 情况 下 也 并 不 
需要 修改 任何 RabbitMQ 的 配置 。 当 然 ， 为 了 更 加 有 效 地 操控 RabbitMQ， 也 可 以 利用 调节 系统 
范围 内 的 参数 来 达到 定制 化 的 需求 。 

RabbitMQ 提供 了 三 种 方式 来 定制 化 服务 : 


(1) 环境 变量 ( Enviroment Variables )。RabbitMQ 服务 端 参数 可 以 通过 环境 变量 进行 配置 ， 
例如 ， 节 点 名 称 、RabbitMQ 配置 文件 的 地 址 、 节 点 内 部 通信 端口 等 。 


(2) 配置 文件 (Configuration File )。 可 以 定义 RabbitMQ 服务 和 插件 设置 ， 例 如 ，TCP 监 
听 端 口 ， 以 及 其 他 网 络 相关 的 设置 、 内 存 限制 、 磁 盘 限 制 等 。 

(3) 运行 时 参数 和 策略 (Runtime Parameters and Policies )。 可 以 在 运行 时 定义 集群 层面 的 
服务 设置 。 

对 于 不 同 的 操作 系统 和 不 同 的 RabbitMQ 安装 包 来 说 ， 相 应 的 配置 会 有 所 变化 ， 包 括 相 应 
的 配置 文件 的 地 址 等 ， 在 使 用 时 要 尤为 注意 。 
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6.1 “环境 变量 


RabbitMQ 的 环境 变量 都 是 以 “RABBITMQ_” 开 头 的 ， 可 以 在 Shell 环境 中 设置 ， 也 可 以 在 
rabbitmq-env.conf 这 个 RabbitMQ 环境 变量 的 定义 文件 中 设置 。 如 果 是 在 非 Shell 环境 中 
配置 ， 则 需要 将 “RABBITMO_ ”这 个 前 缀 去 除 。 优 先 级 顺序 按照 Shell 环境 最 优先 ， 其 次 
rabbitmq-env.conf 配置 文件 ， 最 后 是 默认 的 配置 。. 


当 采 用 rabbitmq-server -detached 启动 RabbitMQ 服务 的 时 候 ， 此 服务 节点 默认 以 
“rabbit@” 加 上 当前 的 Shell 环境 的 hostname (EHL) 来 命名 ， 即 rabbit@$HOSTNAME。 参 
考 下 面 ， 当 前 Shell 环境 的 hostname 为 “nodel”。 


[root@nodel~]# hostname 

nodel 

[root@nodel~]# rabbitmq-server -detached 

Warning: PID file not written; -detached was passed. 
[root@nodel ~]# rabbitmqctl cluster status 

Cluster status of node rabbitünodel 

[(nodes, [(disc,[rabbit8nodel])]]), 
(running nodes, [rabbitG8nodel]], 
(cluster name,««"rabbiteénodel"»»], 


(partitions, []}, 
(alarms,[(rabbitG8nodel,[])])] // 有 些 比 较 旧 的 版 本 是 没有 alarms 这 一 项 的 


如 果 需 要 制定 节点 的 名 称 , 而 不 是 采用 默认 的 方式 , 可 以 在 rabbitmq-server 命令 前 添 
加 RABBITMQ NODENAME 变量 来 设 定 指定 的 名 称 。 如 下 所 示 ， 此 时 创建 的 节点 名 称 为 


“rabbit@node2” 而 非 “rabbit@nodel”。 


[root@nodel ~]# RABBITMQ NODENAME=rabbit@node2 rabbitmq-server -detached 
Warning: PID file not written; -detached was passed. 


DERE 


如 果 先 执行 RABBITMO NODENAME-rabbitGénodel, ， 再 执行 rabbitmq-server 
-detached 人 命令， 相当 于 只 执行 rabbitmq-server -detached 命令 ， 即 对 
RABBITMQ NODENAME 的 定义 无 效 。 
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以 RABBITMQ NODENAME 这 个 变量 为 例 , RabbitMQ 在 启动 服务 的 时 候 首先 判断 当前 Shell 
环境 中 有 无 RABBITMQ NODENAME 的 定义 ， 如 果 有 则 启用 此 值 ， 如 果 没 有 ， 则 查看 
rabbitmq-env.conf 中 是 否定 义 了 NODENAME 这 个 变量 ， 如 果 有 则 启用 此 值 ， 如 果 没 有 则 
采用 默认 的 取 值 规则 ， 即 rabbite$HOSTNAME. 


下 面 演示 如 何 配置 rabbitmq-env.conf 这 个 文件 〈 默 认 在 $SRABBITMQO_HOME/etc/ 
rabbitmq/ 目 录 下 ,可 以 通过 在 启动 RabbitMQ 服务 时 指定 RABBITMQ CONF ENV FILE 变量 来 
设置 此 文件 的 路 径 ): 


# RabbitMQ 环境 变量 的 定义 文件 

# 定义 节点 名 称 

NODENAME=rabbit@nodel 

# 定义 RabbitMo 的 对 外 通信 端口 号 

NODE PORT=5672 

+ 定义 RabbitMo 配置 文件 的 目录 ， 注 意 对 于 rabbitmq.config 
# 文件 来 说 这 里 不 用 添加 、 .config 后 级 ” 

CONFIG FILE=/opt/rabbitmq/etc/rabbitmq/rabbitmq 


对 于 默认 的 取 值 规则 , 这 个 在 $SRABBITMO HOME/sbin/rabbitmq-defaults 文件 中 有 
相关 设置 ， 当 然 也 可 以 通过 修改 这 个 文件 中 的 内 容 来 修改 RabbitMQ 的 环境 变量 ， 但 是 并 不 推 
荐 这 么 做 , 还 是 建议 读者 在 rabbitmq-env.conf 中 进行 相应 的 设置 .rabbitmq-defaults 





#!/bin/sh -e 

## The contents of this file are subject to the Mozilla Public License 
## Version 1.1 (the "License"); you may not use this file except in 

## compliance with the License. You may obtain a copy of the License 
## at http://www.mozilla.org/MPL/ 

## 

## Software distributed under the License is distributed on an "AS IS" 
## basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See 
## the License for the specific language governing rights and 

## limitations under the License. 

LE 

14 The Original Code is RabbitMQ. 

H 

## The Initial Developer of the Original Code is GoPivotal, Inc. 


++ 
H 


Copyright (c) 2012-2015 Pivotal Software, Inc. All rights reserved. 
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### next line potentially updated in package install steps 
SYS PREFIX-$(RABBITMQ HOME] 


### next line will be updated when generating a standalone release 
ERL DIR- 


CLEAN BOOT FILE-start clean 
SASL BOOT FILE-start sasl 


if [ -f "S(RABBITMQ HOME]/erlang.mk" ]; then 

4 RabbitMQ is executed from its source directory. The plugins 
# directory and ERL LIBS are tuned based on this. 
RABBITMQ DEV ENV-1 

fi 


14 Set default values 
BOOT MODULE-"rabbit" 


CONFIG FILE-$(SYS PREFIX]/etc/rabbitmq/rabbitmq 

LOG BASE-$(SYS PREFIX)/var/log/rabbitmq 

MNESIA BASE-$(SYS PREFIX)/var/lib/rabbitmqg/mnesia 

ENABLED PLUGINS FILE-$(SYS PREFIX])/etc/rabbitmqg/enabled plugins 


PLUGINS DIR-"$(RABBITMQ HOME) /plugins" 


RABBIT HOME can contain a version number, so default plugins 
directory can be hard to find if we want to package some plugin 
separately. When RABBITMQ HOME points to a standard location where 
it's usually being installed by package managers, we add 
"/usr/lib/rabbitmg/plugins" to plugin search path. 

case "SRABBITMQ HOME" in 

/usr/lib/rabbitmqg/*) 

PLUGINS DIR-"/usr/lib/rabbitmq/plugins:$PLUGINS DIR" 

'"t' 


esac 


THe cHe che che 6 


CONF ENV FILE-$(SYS PREFIX]/etc/rabbitmq/rabbitmq-env.conf 
表 6-1 中 梳理 一 些 常见 的 RabbitMQ 变量 ， 这 里 包括 但 不 仅 限 于 这 些 变量 。 


表 6-1 常见 的 RabbitMQ 变量 


BTVO NODE JP ADDRESS | 纪 定 某 个 特定 的 网 络 接口 。 默认 值 是 空 字符 串 ， 即 绑 定 到 所 有 网 络 接口 上 。 如果 要 
Q NODE TP. 绑 定 两 个 或 者 更 多 的 网 络 接口 ， 可 以 参考 rabbitmq config 中 的 tcp. listeners 配置 
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续 表 
变量 名 称 
IP MORES. RUN 5672 


RabbitMQ 节点 内 部 通信 的 端口 号 ， 默 认 值 为 RABBITMQ_NODE_PORT+20000， 
即 25672。 如 果 设置 了 kernelinet dist listen min 或 者 kernel.inect dist listen max 
时 ， 此 环境 变量 将 被 忽略 


——— RabbitMQ 的 节点 名 称 ， 默 认为 rabbit@$SHOSTNAME。 在 每 个 Erlang 节点 和 机 器 
2 的 组 合 中 ， 节 点 名 称 必须 唯一 


RabbitMQ 环境 变量 的 配置 文件 (rabbitmq-env.conf) 的 地 址 ， 默 认 值 为 
RABBITMQ CONF ENV_FILE SRABBITMQ HOME/etc/rabbitmq/rabbitmq-env.conf 

注意 这 里 与 RabbitMQ 配置 文件 rabbitmq.config 的 区 别 

如 果 当 前 的 hostname 为 nodel.longname， 那 么 默认 情况 下 创建 的 节点 名 称 为 
RABBITMQ USE LONGNAME rabbit@nodel， 将 此 参数 设置 为 true 时 ， 创 建 的 节点 名 称 就 为 

rabbit@nodel.longname， 即 使 用 了 长 名 称 命名 。 默 认 值 为 空 


ee ge RabbitMQ 配置 文件 (rabbitmq.config) 的 路 径 ， 注 意 没 有 “.config” 的 后 级 。 默 认 值 
Q_ £3 Z3$RABBITMQ HOMEJ/etc/rabbitmq/rabbitmq 


RABBITMQ MNESIA DIR 的 父 目 录 。 除 非 明确 设置 了 RABBITMQ_MNESIA_DIR 
目录 ， 和 否则 每 个 节点 都 应 该 配置 这 个 环境 变量 。 默 认 值 为 
RABBITMQ_MNESIA_BASE $RABBITMQ_HOME/varlib/rabbitmq/mnesia 

注意 对 于 RabbitMQ 的 操作 用 户 来 说 ， 需 要 有 对 当前 目录 可 读 、 可 写 、 可 创建 文件 
及 子 目录 的 权限 


gorvo Mes | 包含 RabbitMQ 服务 节点 的 数据 库 、 数 据 存储 及 集群 状态 等 目录 ， 默 认 值 为 
RABBITMQ MNESIA DIR 

SRABBITMQ MNESIA BASE/SRABBITMQ NODENAME 

RabbitMQ 服务 日 志 所 在 基础 目录 。 默认 值 为 SRABBITMQ_HOME/var/log/rabbitmq 


RabbitMQ 服务 与 Erlang 相关 的 日 志 ， 默 认 值 为 
RABBITMQ LOGS 
$RABBITMQ LOG BASE/SRABBITMQ NODENAME.log 











RABBITMQ DIST PORT 














RabbitMQ 服务 于 Erlang 的 SASL(System Application Support Libraries) 相 关 的 日 志 ， 
默认 值 为 ?RABBITMQ LOG BASE/SRABBITMQ NODENAME:-sasl.log 


插件 所 在 路 径 。 默 认 值 为 SRABBITMQ_HOME/plugins 


注意 ,如 果 没 有 特殊 的 需求 , 不 建议 更 改 RabbitMQ 的 环境 变量 。 如 果 在 实际 生产 环境 中 ， 
对 于 配置 和 日 志 的 目录 有 着 特殊 的 管理 目录 ， 那 么 可 以 参考 以 下 相应 的 配置 ， 


# 配 置 文件 的 地 址 

CONFIG FILE-/apps/conf/rabbitmq/rabbitmq 

# 环 境 变量 的 配置 文件 的 地 址 

CONF ENV FILE-/apps/conf/rabbitmq/rabbitmq-env.conf 
# 服 务 日 志 的 地 址 

LOG BASE-/apps/logs/rabbitmq 

iMnesia 的 路 径 






RABBITMQ_SASL_LOGS 
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MNESIA BASE-/apps/dbdat/rabbitmq/mnesia 


62 ”配置 文件 


前 面 提 到 默认 的 配置 文件 的 位 置 取决 于 不 同 的 操作 系统 和 安装 包 。 最 有 效 的 方法 就 是 检查 
RabbitMQ 的 服务 日 志 , 在 启动 RabbitMQ 服务 的 时 候 会 打印 相关 信息 。 如 下 所 示 , 其 中 的 “config 
files(s)” 为 目前 的 配置 文件 所 在 的 路 径 。 


-INFO REPORT==== 27-Jun-2017::19:30:08 === 

node : rabbit@nodel 

home dir : root 

config file(s): /opt/rabbitmqg/sbin/../etc/rabbitmqg/rabbitmq.config 

cookie hash : K9v2VnrpjB5ZmdgTFb2XTOQ-- 

log : /opt/rabbitmq/sbin/../var/log/rabbitmq/rabbit8(nodel.log 

sasl log : /opt/rabbitmqg/sbin/../var/log/rabbitmq/rabbit8nodel-sasl.log 


database dir : /opt/rabbitmqg/sbin/../var/lib/rabbitmq/mnesia/rabbitG8nodel 


在 实际 应 用 中 ， 可 能 会 遇 到 明明 设置 了 相应 的 配置 却 没有 生效 的 情况 ， 也 许 是 RabbitMQ 
启动 时 并 没有 能 够 成 功 加 载 到 相应 的 配置 文件 ， 如 下 所 示 。 


config file(s) : /opt/rabbitmq/sbin/../etc/rabbitmq/rabbitmq.config (not found) 


如 果 看 到 有 “not found” 标 识 ， 那 么 可 以 检查 日 志 打印 的 路 径 中 有 没有 相关 的 配置 文件 ， 
或 者 检查 配置 文件 的 地 址 是 否 设 置 正确 (通过 RABBITMQ CONFIG FILE 变量 或 者 
rabbitmq-env.conf 文件 设置 )。 如 果 rabbitmq.config 文件 不 存在 ， 可 以 手动 创建 它 。 

还 可 以 通过 查看 进程 信息 的 方式 来 检查 配置 文件 的 位 置 。 通 过 ps aux1grep rabbitmq 
命令 查看 到 RabbitMQ 进程 的 信息 ， 如 果 rabbitmq.config 文件 不 处 于 默认 的 路 径 中 ， 则 会 
有 -config 选项 标记 正在 使 用 的 路 径 ， 如 以 下 示例 中 的 加 粗 部 分 : 


[root@nodel rabbit@nodel]# ps aux |grep rabbitmq 


root 20503 9.6 0.9 3906904 72912 ? S1 19:23 0:04 /opt/erlang/ 
lib/erlang/erts-8.1/bin/beam.smp -W w -A 64 -P 1048576 -t 5000000 -stbt db -zdbbl 
32000 -K true -- -root /opt/erlang/lib/erlang -progname erl -- -home /root -- -pa 


/opt/rabbitmg/ebin -noshell -noinput -s rabbit boot -sname rabbit@nodel -boot start 
sasl -config /etc/rabbitmq/rabbitmq -kernel inet default connect options [(nodelay, 


true]] -sasl errlog type error -sasl sasl error logger false -rabbit error logger 
(file,"/opt/rabbitmq/var/log/rabbitmq/rabbitG8nodel.log") -rabbit sasl error - 
logger [(file,"/opt/rabbitmg/var/log/rabbitmq/rabbitG(nodel-sasl.log") -rabbit 
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enabled plugins file "/opt/rabbitmq/etc/rabbitmq/enabled plugins" -rabbit plugins 
dir "/opt/rabbitmq/plugins" -rabbit plugins expand dir "/opt/rabbitmq/var/lib/ 
rabbitmg/mnesia/rabbit8nodel-plugins-expand" -os mon start cpu sup false -os mon 
Start disksup false -os mon start memsup false -mnesia dir "/opt/rabbitmqg/var/lib/ 
rabbitmg/mnesia/rabbit8nodel" -kernel inet dist listen min 25672 -kernel inet dist _ 
listen max 25672 -noshell -noinput 


6.2.1 配置 项 


一 个 极 简 的 rabbitmq.config 文件 配置 :如 以 下 代码 所 示 〈 注 意 包含 尾部 的 点 号 ): 
[ 
rabbit, [ 
(tcp listeners, [5673]) 
] 
e 


上 面 的 配置 将 RabbitMQ 监听 AMQP 0-9-1 客户 端 连 接 的 默认 端口 号 从 5672 修改 为 5673. 
在 后 面 第 8 章 中 的 Shove 及 第 10 章 中 的 网 络 分 区 处 理 都 会 涉及 rabbitmq.config 的 使 用 。 


表 6-2 中 展示 了 与 RabbitMQ 服务 相关 的 大 部 分 配置 项 。 如 无 特殊 需要 ， 不 建议 贸然 修改 
这 些 默认 配置 。 注 意 ， 与 插件 有 关 的 配置 并 未 在 表 6-2 中 列 出 。 


表 6-2 RabbitMQ 服务 相关 配置 


用 来 监听 AMQP 连接 (无 SSL)。 可 以 配置 为 端口 号 或 者 端口 号 与 主机 名 组 成 的 二 
元 组 。 示 例如 下 : 
[{rabbit, [{tcp_listeners, [{"192.168.0.2", 5672}]}]}]. 


tep listeners 


或 者 
[{rabbit, [{tcp_listeners, [{"127.0.0.1", 5672), {"::1", 5672)])])]. 
默认 值 为 [5672] 


用 来 处 理 TCP 连接 的 Erlang 进程 数目 ， 默 认 值 为 10 





1 一 个 比较 完整 的 配置 案例 可 以 参考 : https://github.com/rabbitmq/rabbitmq-server/blob/stable/docs/rabbitmq.config.example， 这 个 
示例 文件 中 包含 了 大 多 数 配 置 项 与 其 相应 的 说 明 ， 示 例 中 的 所 有 配置 项 都 做 了 注释 。 注 意 ， 示 例文 件 仅 仅 是 示例 文件 ， 不 应 该 
将 其 视 为 通用 的 推荐 配置 。 
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gk 


1 AMQP 0-8/0-9/0-9-1 握手 (在 socket 连接 和 SSL 握手 之 后 ) 的 超时 时 间 ， 单 位 为 毫 
handshake timeout $ 
-= 秒 。 默 认 值 为 10000 


内 存 使 用 的 报告 方式 。 一 共有 2 种 

(1) rss: 采用 操作 系统 的 RSS 的 内 存 报告 

(2) erlang: 采用 Erlang 的 内 存 报告 

默认 值 为 rss 

内 存 高 水 位 的 百分比 阔 值 ， 当 达到 阔 值 时 ， 队 列 开始 将 消息 持久 化 到 磁盘 以 释放 内 
存 。 这 个 需要 配合 vm_memory_high_watermark 这 个 参数 一 起 使 用 。 默 认 值 为 0.5。 
更 多 详细 内 容 请 参考 9.2 节 

RabbitMQ 存储 数据 分 区 的 可 用 磁盘 空间 限制 。 当 可 用 空间 值 低 于 闪 值 时 ， 流 程控 制 
将 被 触发 。 此 值 可 根据 RAM 的 相对 大 小 来 设置 (如 {mem_relative, 1.0} )。 此 值 也 可 
以 设 为 整数 〈 单 位 为 B)， 或 者 使 用 数字 + 单位 〈 如 “50MB”)。 默 认 情况 下 ， 可 用 
磁盘 空间 必须 超过 S0MB。 默 认 值 为 50000000 

控制 日 志 的 粒度 。 该 值 是 日 志 事件 类 别 〈category) 和 日 志 级 别 〈level) 的 二 元 组 列 
表 

目前 定义 了 4 种 日 志 类 别 

(12 channel: 所 有 与 AMQP 信道 相关 的 日 志 

(2) connection: 所 有 与 连接 相关 的 日 志 

(3) federation: 所 有 与 federation 相关 的 日 志 

(4) mirroring: 所 有 与 镜像 相关 的 日 志 

其 他 未 分 类 的 日 志 也 会 被 记录 下 来 

日 志 级 别 有 5 种 : none 表示 不 记录 日 志 事件 ，error 表示 只 记录 错误 ，warning 表示 
只 记录 错误 和 告警 ，info 表示 记录 错误 、 告 警 和 信息 ; debug 表示 记录 错误 、 告 警 、 
信息 和 调试 信息 
默认 值 为 [{connection, info}] 


与 客户 端 协商 的 允许 最 大 帧 大 小 ， 单 位 为 B。 设 置 为 0 表示 无 限制 ， 但 在 某 些 QPid 
frm ara 客户 端 会 引发 bug。 设置 较 大 的 值 可 以 提高 吞吐 量 ; 设置 一 个 较 小 的 值 可 能 会 提高 延 
3R. ERA ÉL 131072 
ET 与 客户 端 协商 的 允许 最 大 信道 个 数 。 设 置 为 0 表示 无 限制 。 该 数值 越 大 ， 则 Broker 
CUT 的 内 存 使 用 就 越 高 。 默 认 值 为 0 
TE RID VOR 信道 运行 的 超时 时 间 ， 单 位 为 毫秒 (内 部 使 用 ， 因 为 消息 协议 的 区 别 和 限制 ， 不 暴 
€ fel operation | eoul 露 给 客户 端 )。 默认 值 为 15000 
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续 表 
服务 器 和 客户 端 连接 的 心跳 延迟 ， 单 位 为 秒 。 如 果 设置 为 0， 则 禁用 心跳 。 在 有 大 量 
heartbeat 连接 的 情况 下 ， 禁 用 心跳 可 以 提高 性 能 ， 但 可 能 会 导致 一 些 异常 。 默 认 值 为 60。 在 
3.5.5 版 本 之 前 为 580 


设置 只 能 通过 本 地 网 络 〈 如 localhost) 来 访问 Broker 的 用 户 列表 。 如 果 希 望 通过 默 
Jeogback aos 认 的 guest 用 户 能 够 通过 远程 网 络 访问 Broker， 那 么 需要 将 这 项 设置 为 []。 默 认 值 为 
<<"guest">> 
E 可 以 用 来 配置 集群 。 这 个 值 是 一 个 二 元 组 ， 二 元 组 的 第 一 个 元 素 是 想 要 与 其 建立 集 
icon dA 群 关 系 的 节点 ,第 二 个 元 素 是 节点 的 类 型 ,要 么 是 disc, 要 么 是 ram。 默 认 值 为 {[], disc) 


连接 时 向 客户 端 声明 的 键 值 对 列表 。 默 认 值 为 [] 
统计 数据 的 收集 模式 ， 主 要 与 RabbitMQ Management 插件 相关 ， 共 有 3 个 值 可 选 : 
(1) none: 不 发 布 统计 事件 


collect statistics (2) coarse: 发 布 每 个 队列 /信道 /连接 的 统计 事件 


(3) fine: 同时 还 发 布 每 个 消息 的 统计 事件 
默认 值 为 none 


统计 数据 的 收集 时 间 间隔 ， 主 要 与 RabbitMQ Management 插件 相关 。 默 认 值 为 5000 
< 设置 管理 插件 将 缓存 代价 较 高 的 查询 的 时 间 。 缓 存 将 把 最 后 一 个 查询 的 运行 时 间 乘 
management db cache multiplier 以 这 个 值 ， 并 在 此 时 间 内 缓存 结果 。 默 认 值 为 5 
m 内 部 集群 通信 中 ， 委 派 进程 的 数目 。 在 拥有 很 多 个 内 核 并 且 是 集群 中 的 一 个 节点 的 
PIORA NON 机 器 上 可 以 增加 此 值 。 默 认 值 为 16 


默认 的 socket 选项 。 默 认 值 为 : 
[(backlog, 128}, 
tcp listen options {nodelay, true}, 
(linger, {true,0}}, 


fexit on close, false}] 


将 此 项 设置 为 true 就 可 以 开启 HiPE 功能 ， 即 Erlang 的 即时 编译 器 。 虽 然 在 启动 时 
会 增加 时 延 ， 但 是 能 够 有 20% 一 50% 的 性 能 提升 ， 当 然 这 个 数字 高 度 依赖 于 负载 和 
ipe. naie 机 器 硬件 。 在 你 的 Erlang 安装 包 中 可 能 没有 包含 HiPE 的 支持 ， 如 果 没 有 ， 则 在 开启 
SS 这 一 项 ， 并 且 在 RabbitMQ 启动 时 会 有 相应 的 告警 信息 。HiPE 并 非 在 所 有 平台 都 可 
以 ， 尤 其 是 Windows 操作 系统 。 在 Erlang/OTP17.5 版 本 之 前 ，HiPE 有 明显 的 问题 。 
如 果 要 使 用 HiPE 推荐 使 用 最 新 版 的 Erlang/OTP。 默 认 值 为 false 
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续 表 


如 何 处 理 网 络 分 区 。 有 4 种 取 值 : ignore: pause minority; (pause if all down, [nodes], 
ignore | autoheal}; autoheal 

默认 值 为 false 

详细 请 参考 第 10 章 的 内 容 


PERRA 向 其 他 节点 发 送 存活 消息 的 频率 。 单 位 为 毫秒 。 这 个 参数 和 net, ticktime 参数 不 同 ， 
UMP 丢失 存活 消息 并 不 会 导致 节点 被 认为 已 失效 。 默 认 值 为 10000 


消息 的 大 小 小 于 此 值 时 会 直接 嵌入 到 队列 的 索引 中 。 单 位 为 B。 默 认 值 为 4096 


cluster partition handling 


3 "S 
. 队列 索引 的 实现 模块 。 默 认 值 为 
msg store index module 
rabbit msg store ets index 
i H 


队列 内 容 的 实现 模块 。 默 认 值 为 rabbit_variable_queue。 不 建议 修改 此 项 


SCRI 默认 值 为 10 
每 次 重 试 时 ， 等 待 集群 中 Mnesia 数据 表 可 用 时 的 超时 时 间 
-tele oading org 默认 值 为 30000 


队列 的 定位 策略 ， 即 创建 队列 时 以 什么 策略 判断 坐落 的 Broker 节点 。 如 果 配 置 了 镜 
像 ， 则 这 里 指 master 镜像 的 定位 策略 
可 用 的 策略 有 : <<"min-masters">>、<<"client-local">>、<<"random">>。 默 认 值 为 


<<"client-local">> 
lazy queue explicit gc run operatio | 在 使 用 惰性 队列 (lazy queue) 时 进行 内 存 回收 动作 的 阔 值 。 一 个 低 的 值 会 降低 性 能 ， 
n threshold 一 个 高 的 值 可 以 提高 性 能 ， 但 是 会 导致 更 高 的 内 存 消耗 。 默 认 值 为 1000 


queue explicit gc run operation thr | 在 使 用 正常 队列 时 进行 内 存 回收 动作 的 阔 值 。 一 个 低 的 值 会 降低 性 能 ， 一 个 高 的 值 
eshold 可 以 提高 性 能 ， 但 是 会 导致 更 高 的 内 存 消 耗 。 默 认 值 为 1000 


62.2 ”配置 加 密 


queue master locator 





配置 文件 中 有 一 些 敏 感 的 配置 项 可 以 被 加 密 ， 然 后 在 RabbitMQ 启动 时 可 以 对 这 些 项 进行 
解密 。 对 这 些 项 进行 加 密 并 不 是 意味 着 系统 的 安全 性 增强 了 ， 而 是 遵从 一 些 必要 的 规范 ， 让 一 
些 敏感 的 数据 不 会 出 现在 文本 形式 的 配置 文件 中 。 在 配置 文件 中 将 加 密 之 后 的 值 以 
“{encrypted, 加 密 的 值 } ”形式 包裹 ， 比 如 下 面 的 示例 中 使 用 口令 “zzhpassphrase” 将 密 
码 “guest” 加 密 。 


rabbit,[ 
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{default user,<<"guest">>}, 
{default pass, 
{ 
{encrypted, <<"HuVPYgSUdbogWL+2jGsgDMGZpDfiz+HurDuedpG8d 
QX/U+DMHcBluAl5a5jRnAbs+OviX5EmsJJ+c0XgRRCADA==">>} 
} 
}， 
(loopback users,[]], 
(config entry decoder,[ 
(passphrase,««"zzhpassphrase"»») 
1} 


E 


config entry decoder 项 中 的 passphrase 配置 的 就 是 口令 。 注 意 这 里 将 
loopback users 项 配置 为 [] ， 就 可 以 使 用 非 本 地 网 络 访问 RabbitMQ 了 ， 如 果 开 启 了 
RabbitMQ Management 插件 ， 就 可 以 使 用 guest/guest 的 用 户 及 密码 来 访问 Web 管理 界面 了 。 


passphrase 项 中 的 内 容 不 一 样 要 以 硬 编码 的 形式 呈现 ， 还 可 以 使 用 单独 文件 来 赋值 ， 示 
例 参考 如 下 : 
[ 
{rabbit, [ 


(config entry decoder, [ 
(passphrase, (file, "/path/to/passphrase/file"]] 
1) 
1] 
Je 


这 里 就 有 疑问 了 ，encrypted 项 中 的 一 长 串 的 加 密 后 的 值 从 何 而 来 ? 这 里 就 用 到 了 
rabbitmqctl encode 命令 ， 如 下 所 示 。 


[root@nodel ~]# rabbitmqctl encode '<<"guest">>' zzhpassphrase 
(encrypted, ««"HuVPYgSUdbogWL*2jGsgDMGZpDfiz*HurDuedpG8dQX/U*DMHcBluAl5a5jRnA 
bstOviX5EmsJJ-*cOXgRRCADA--"»»] 


对 应 的 解密 示例 如 下 : 


[root@nodel ~]# rabbitmqctl encode --decode '{encrypted,<<"L9QUE5RGFB2eEd8uwpjb 
UpALmMGAJwXjf2sTcGLhxwCVsICtNAql1XX7O0WxJ2nwxN5PGmVlCOAlTy3C6n9RKX1g--2"»»]' zzhpass 
phrase 

««"guest"»» 


默认 情况 下 ， 加 密 机 制 PBKDF2 用 来 从 口令 中 派生 出 密 钥 。 默 认 的 Hash 算法 是 SHAS12, 
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默认 的 迭代 次 数 是 1000, 以 及 默认 的 加 密 算 法 为 AES_256_CBC。 可 以 在 配置 文件 中 进行 修改 ， 
示例 如 下 : 
[ 
(rabbit, [ 


(config entry decoder, [ 
(passphrase, "zzhpassphrase")], 
(cipher, blowfish cfb64}, 
(hash, sha256}, 
(iterations, 10000) 

1) 
11 
To 


或 者 通过 rabbitmqctl encode 命令 设置 : 


rabbitmqctl encode --cipher blowfish cfb64 --hash sha256 --iterations 10000 
'««"guest"»»' zzhpassphrase 


rabbitmqctl encode 的 完整 命令 为 : 


rabbitmqctl encode [--decode] [«value»] [«passphrase»] [--list-ciphers] 
[--list-hashes] [--cipher «cipher»] [--hash «hash»] [--iterations «iterations»] 


命令 中 的 参数 在 前 面 的 内 容 中 基本 都 有 涉及 ， 剩 余 的 [--1ist-ciphers]. 
[--1ist-hashes] 两 个 参数 分 别 用 来 罗列 当前 RabbitMQ 所 支持 的 加 密 算法 和 Hash 算法 。 示 
例如 下 : 


[root@nodel ~]# rabbitmqctl encode --list-ciphers 

[des3 cbc,des ede3,des3 cbf,des3 cfb,aes cbc,aes cbcl28,aes cfb8,aes cfb128, 
aes cbc256,aes ige256,des cbc,des cfb,blowfish cbc,blowfish cfb64, 

blowfish ofb64,rc2 cbc] 

[root@nodel rabbitmq]# rabbitmqctl encode --list-hashes 

[sha, sha224, sha256, sha384, sha512,md5] 


6.2.3 ”优化 网 络 配置 
网 络 是 客户 端 和 RabbitMQ 之 间 通 信 的 媒介 。RabbitMQ 支持 的 所 有 协议 都 是 基于 TCP 层 


面 的 。 包 括 操作 系统 和 RabbitMQ 本 身 都 提供 了 许多 可 调节 的 参数 ， 除 了 操作 系统 内 核 参 数 和 
DNS， 所 有 的 RabbitMQ 设置 都 可 以 通过 在 rabbitmq.config 配置 文件 中 配置 来 实现 。 
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网 络 本 身 就 是 一 个 非常 宽泛 的 话题 ， 其 中 涉及 许多 的 配置 选项 ， 这 些 选 项 可 以 对 某 些 任务 
产生 积极 的 或 者 消极 的 影响 。 本 节 并 不 襄 括 所 有 的 知识 点 ， 而 是 提供 一 些 关键 的 可 调节 参数 的 
索引 ， 以 作 抛 砖 引 玉 之 用 。 


RabbitMQ 在 等 待 接收 客户 端 连 接 时 需要 绑 定 一 个 或 者 多 个 网 络 接口 (可 以 理解 成 卫 地 址 )， 
并 监听 特定 的 端口 。 网 络 接口 使 用 rabbit.tcp listeners 选项 来 配置 。 默 认 情 况 下 ， 
RabbitMQ 会 在 所 有 可 用 的 网 络 接口 上 监听 5672 端口 。 下 面 的 示例 演示 了 如 何在 一 个 指定 的 IP 
地 址 和 端口 上 进行 监听 : 
[ 
{rabbit, [ 
(tcp listeners, [("192.168.0.2", 5672)]) 
1) 
Jz 
同时 监听 IPv4 和 IPv6 上 监听 ， 示 例如 下 : 


[ 
(rabbit, [ 
(tcp listeners, [("127.0.0.1", 5672], 
("st 5672113 
1) 
J> 
优化 网 络 配置 的 一 个 重要 目标 就 是 提高 吞吐 量 ， 比 如 禁用 Nagle 算法 、 增 大 TCP 缓冲 区 的 
大 小 。 每 个 TCP 连接 都 分 配 了 缓冲 区 。 一 般 来 说 ， 缓 冲 区 越 大 ， 吞 吐 量 也 会 越 高 ， 但 是 每 个 连 
接 上 耗费 的 内 存 也 就 越 多 ， 从 而 使 总 体 服务 的 内 存 增 大 ， 这 是 一 个 权衡 的 问题 。 在 Linux 操作 
系统 中 ， 默 认 会 自动 调节 TCP 缓冲 区 的 大 小 ， 通 常会 设置 为 80KB 到 120KB 之 间 。 要 提高 吞 
吐 量 可 以 使 用 rabbit.tcp listen options 来 加 大 配置 。 下 面 的 示例 中 将 TCP 缓冲 区 大 
小 设置 为 192KB: 
[ 


(rabbit, I 
(tcp listen options, [ 

(backlog, 128], 
(nodelay, true), 
(linger, {true,0}}, 
{exit on close, false}, 
{sndbuf, 196608), 
(recbuf, 196608} 
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Erlang 在 运行 时 使 用 线程 池 来 异步 执行 IO 操作 。 线 程 池 的 大 小 可 以 通过 
RABBITMQ SERVER ADDITIONAL ERL ARGS 这 个 环境 变量 来 调节 。 示 例如 下 : 


RABBITMQ SERVER ADDITIONAL ERL ARGS="+A 128" 


目前 3.6.x 版 本 的 默认 值 为 128。 当 机 器 的 内 核 个 数 大 于 等 于 8 时 ， 建 议 将 此 值 设置 为 大 于 
等 于 96, 这 样 可 以 确保 每 个 内 核 上 可 以 运行 大 于 等 于 12 个 VO 线程 。 注 意 这 个 值 并 不 是 越 高 越 
能 提高 吞吐 量 。 


大 部 分 操作 系统 都 限制 了 同一 时 间 可 以 打开 的 文件 句柄 数 。 在 优化 并 发 连接 数 的 时 候 ， 需 
确保 系统 有 足够 的 文件 句柄 数 来 支撑 客户 端 和 Broker 的 交互 。 可 以 用 每 个 节点 上 连接 的 数目 乘 
以 1.5 来 粗略 的 估算 限制 。 例 如 ， 要 支撑 10 万 个 TCP 连接 ， 需 要 设置 文件 句柄 数 为 15 万 。 当 
然 ， 略 微 增 加 文件 句柄 数 可 以 增加 闲置 机 器 内 存 的 使 用 量 ， 但 这 需要 合理 权衡 。 


如 上 所 述 ， 增 大 TCP 缓冲 区 的 大 小 可 以 提高 乔 吐 量 ， 如 果 减 小 TCP 缓冲 区 的 大 小 ， 这 样 
就 可 以 减 小 每 个 连接 上 的 内 存 使 用 量 。 如 果 并 发 量 比 吞吐 量 更 重要 ， 可 以 修改 此 值 。 


前 面 所 提 到 的 禁用 Nagle 算法 可 以 提高 吞吐 量 ， 但 是 其 主要 还 是 用 于 减少 延迟 。RabbitMQ 内 
部 节点 交互 时 可 以 在 kernel.inet default connect options 和 kernel.inet _ 
default listen options 配置 项 中 配置 {fnodelay， true} 来 禁用 Nage 算法 。 
rabbit.tcp listen options 也 需要 包含 同样 的 配置 ， 并 且 默 认 都 是 这 样 配置 的 ， 参 考 下 面 


示例 : 
[ 


{kernel, [ 
(inet default connect options, [{nodelay, true}]}, 
(inet default listen options, ([ínodelay, true}]} 
1) 
(rabbit, [ 
(tcp listen options, [ 
(backlog, 4096), 
(nodelay, true], 
(linger, {true,0}}, 


{exit on close, false} 
13 
1) 
]. 
当 优化 并 发 连接 数 时 ， 恰 当 的 Erlang 虚拟 机 的 UO 线程 池 的 大 小 也 很 重要 ， 有 具体 可 以 参考 


前 面 的 内 容 。 
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当 只 有 少量 的 客户 端 时 ， 新 建立 的 连接 分 布 是 非常 不 均匀 的 ， 但 是 由 于 数量 足够 小 ， 所 以 没 
有 太 大 的 差异 。 当 连接 数量 到 达 数 万 或 者 更 多 时 ， 重 要 的 是 确保 服务 器 能 够 接受 入 站 连接 。 未 接 
受 的 TCP 连接 将 会 放 在 有 长 度 限制 的 队列 中 。 这 个 通过 rabbit.tcp listen options. 
backlog 参数 来 设置 ， 详 细 内 容 可 以 参考 前 一 个 示例 。 默 认 值 为 128， 当 挂 起 的 连接 队列 的 长 
度 超过 此 值 时 ， 连 接 将 被 操作 系统 拒绝 。 表 6-3 展示 了 TCP 套 接 字 的 几 个 通用 的 选项 。 


表 6-3 通用 的 TCP 套 接 字 选 项 


"EOS true, 可 禁用 Nagle 算法 。 默 认为 we。 对 于 大 多 数 用 户 而 言 ,推荐 设置 为 true 
参考 前 面 讨论 的 TCP 缓冲 区 。 一 般 取 值 范围 在 88KB 至 128KB 之 间 。 增 大 缓冲 区 可 以 
rabbit.tcp listen options.sndbuf 

参考 前 面 讨论 的 TCP 缓冲 区 。 一 般 取 值 范围 同样 在 88KB Æ 128KB 之 间 。 一 般 是 针对 
发 送 者 或 者 协议 操作 

当 套 接 字 关 闭 时 ， 设 置 为 ftue, N}， 用 于 设置 刷新 未 发 送 数据 的 超时 时 间 ， 单 位 为 秒 
10 分 钟 ) 是 有 意义 的 ， 虽 然 更 推荐 使 用 heartbeat 的 选项 

与 操作 系统 有 关 的 网 络 设置 也 会 影响 到 RabbitMQ 的 运行 ， 理 解 这 些 设置 选项 同样 至 关 重 
要 。 注 意 这 一 类 型 的 内 核 参数 在 /etc/sysctl .conf 文件 (Linux 操作 系统 ) 中 配置 ， 而 不 是 


提高 消费 者 的 吞吐 量 ， 同 时 也 会 加 大 每 个 连接 上 的 内 存 使 用 量 。 减 小 则 有 相反 的 效果 
队列 中 未 接受 连接 的 最 大 数目 。 当 达到 此 值 时 ， 新 连接 会 被 拒绝 。 对 于 成 千 上 万 的 并 发 
当 设置 为 tue 时， 启用 TCP 的 存活 时 间 。 默 认为 blse。 对 于 长 时 间 空闲 的 连接 〈 至 少 
rabbit.tcp listen options.keepalive 
f£ rabbitmq.config 这 个 文件 中 。 表 6-4 列 出 一 些 重要 的 可 配置 的 相关 选项 : 




























表 6-4 一 些 可 配置 的 内 核 选项 





内 核 分 配 的 最 大 文件 句柄 数 。 极 限 值 和 当前 值 可 以 通过 /proc/sys/fs/file-nr 来 查看 。 
示例 如 下 : 

[root@nodel ~]# cat /proc/sys/fs/file-nr 

8480 0 798282 


Ab IP 端口 范围 ， 定 义 为 一 对 值 。 该 范围 必须 为 并 发 连接 提供 足够 的 条 目 


fs.file-max 


当 启用 时 ， 人 允许 内 核 重用 TIME, WAIT 状态 的 套 接 字 。 当 用 在 NAT 时 ， 此 选项 是 很 危险 的 


降低 此 值 到 5 一 10 可 减少 连接 关闭 的 时 间 ， 之 后 会 停留 在 TIME WAIT 状态 ， 建 议 用 在 有 
大 量 并 发 连接 的 场景 


net.ipv4.tcp fin timeout 
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net.core.somaxconn 监听 队列 的 大 小 〈 同 一 时 间 建 立 过 程 中 有 多 少 个 连接 )。 默 认为 128。 增 大 到 4096 或 更 高 ， 
可 以 支持 入 站 连接 的 爆发 ， 如 clients 集体 重 连 


netipv4.tep max syn backlog | 尚未 收 到 连接 客户 端 确认 的 连接 请 求 的 最 大 数量 。 默 认为 128， 最 大 值 为 65535。 优 化 吞吐 
量 时 ，4096 和 8192 是 推荐 的 起 始 值 


netipv4.tcp keepalive * netipv4.tcp keepalive time, netipv4.tcp keepalive intvl 和 
netipv4.tcp keepalive probes 用 于 配置 TCP 存活 时 间 


启用 反 向 地 址 过 滤 。 如 果 系统 不 关心 人 P 地 址 欺骗 ， 那 么 就 禁用 它 





6.3 ”参数 及 策略 


RabbitMQ 绝 大 大 多 数 的 配置 都 可 以 通过 修改 rabbitmq.config 配置 文件 来 完成 ， 但 是 其 
中 有 些 配置 并 不 太 适 合 在 rabbitmq.config 中 去 实现 。 比 如 某 项 配置 不 需要 同步 到 集群 中 的 其 
他 节点 中 ,或 者 某 项 配置 需要 在 运行 时 更 改 , 因为 rabbitmq.config 需要 重启 Broker 才能 生效 。 
这 种 类 型 的 配置 在 RabbitMQ 中 的 另 一 种 称呼 为 参数 〈Parameter)， 也 可 以 称 之 为 运行 时 参数 
(Runtime Parameter)。 英 文中 的 “arguments” 也 翻译 为 参数 ， 比 如 channel .basicPublish 方 
法 中 的 参数 就 是 指 “arguments”， 为 了 与 之 能 够 有 效 地 区 分 ， 后 边 都 使 用 Parameter 或 者 Runtime 
Parameter 的 称谓 来 进行 相应 的 阐述 。 


Parameter 可 以 通过 rabbitmqctl 工具 或 者 RabbitMQ Management 插件 提供 的 HTTP API 
接口 来 设置 。RabbitMQ 中 一 共有 两 种 类 型 的 Parameter: vhost 级 别 的 Parameter 和 global 级 别 
的 Parameter。vhost 级 别 的 Parameter 由 一 个 组 件 名 称 (component name)、 名 称 (name) 和 值 
(value) 组 成 ， 而 global 级 别 的 参数 由 一 个 名 称 和 值 组 成 ， 不 管 是 vhost 级 别 还 是 global 级 别 的 
参数 ， 其 所 对 应 的 值 都 是 JSON 类 型 的 。 举 例 来 说 ，Federation upstream 是 一 个 vhost 级 别 的 
Parameter， 它 用 来 定义 Federation link 的 上 游 信息 ， 其 对 应 的 Parameter 的 组 件 名 称 为 
“federation-upstream”， 名 称 对 应 于 其 自身 的 名 称 ， 而 值 对 应 于 与 上 游 的 相关 的 连接 参数 等 ， 对 
于 Shovel 而 言 也 可 以 通过 Parameter 设置 ,其 对 应 组 件 名 称 为 “shovel”。 有关 Federation 或 Shovel 
的 更 多 细节 可 以 参考 第 8 章 。 


vhost 级 别 的 参数 对 应 的 rabbitmqctl 相关 的 命令 有 三 种 : set parameter. 
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list parameters 和 clear parameter. 
rabbitmqctl set parameter [-p vhost] (component name) (name) (value) 


用 来 设置 一 个 参数 。 示 例如 下 例子 中 演示 的 Federation upstream 的 Parameter 设置 ， 需 要 
先 开 启 rabbitmq federation 插件 ): 


[root@nodel ~]# rabbitmq-plugins enable rabbitmq federation 
The following plugins have been enabled: 
rabbitmq federation 

Applying plugin configuration to rabbit8nodel... started 1 plugin. 

[root@nodel ~]# rabbitmqctl set parameter federation-upstream fl '("uri":"amqp: 
//root:root1230192.168.0.2:5672", "ack-mode":"on-confirm")' 

Setting runtime parameter "fl" for component "federation-upstream" to "{\"uri\":\ 
"amqp://root:root1230192.168.0.2:5672N", V"ack-modeV" :V"on-confirmNV")" 


rabbitmqctl list parameters [-p vhost] 


用 来 列 出 指定 虚拟 主机 上 所 有 的 Parameter。 示 例如 下 : 


[root@nodel ~]# rabbitmqctl list parameters -p / 

Listing runtime parameters 

federation-upstream f1 ("uri":"amqp://root:root12380192.168.0.2:5672", "ack- 
mode":"on-confirm") 

rabbitmqctl clear. parameter [-p vhost] (componenet name) (key) 


用 来 清除 指定 的 参数 。 示 例如 下 : 


[root@nodel ~]# rabbitmqctl clear parameter -p / federation-upstream f1 
Clearing runtime parameter "f1" for component "federation-upstream" 
[root(nodel ~]# rabbitmqctl list parameters -p / 

Listing runtime parameters 


与 rabbitmqctl 工具 相对 应 的 HTTP API 接口 如 下 所 述 。 

分 设置 一 个 参数 : PUT /api/parameters/{componenet name}/vhost/name。 
+ 清除 一 个 参数 : DELETE /api/parameters/{componenet name)/vhost/name. 
* 列 出 指定 vhost 中 的 所 有 参数 : GET. /api/parameters。 


global 级 别 Parameter 的 set. clear 和 list 功能 所 对 应 的 rabbitmqctl 工具 与 HTTP API 
接口 如 表 6-5 所 示 。 
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表 6-5 global 级 别 的 Parameter 的 操作 









rabbitmqctl set global parameter name value 
rabbitmqcetl rabbitmqctl list global parameters 
rabbitmqctl clear global parameter name 


PUT /api/global-parameters/name 
HTTP API 接口 DELETE /api/global-parameters/name 


GET /api/global-parameters/ 





global 级 别 的 Parameter 的 示例 如 下 〔 注 意 到 集群 名 称 cluster name 就 是 一 个 global 级 别 的 


[root@nodel ~]# rabbitmqctl list global parameters 
Listing global runtime parameters 

cluster name “rabbit@nodel" 

[root@nodel ~]# rabbitmqctl set global parameter namel '{}' 
Setting global runtime parameter "namel" to "{}" 
[root@nodel ~]# rabbitmqctl list global parameters 
Listing global runtime parameters 

cluster name "rabbit nodel" 

namel [1 

[rooténodel ~]# rabbitmqctl clear global parameter namel 
Clearing global runtime parameter "namel" 

[root@nodel ~]# rabbitmqctl list global parameters 
Listing global runtime parameters 

cluster name "rabbit@nodel" 


除了 一 些 固定 的 参数 〈 比 如 durable 或 者 exclusive)， 客 户 端 在 创建 交换 器 或 者 队列 
的 时 候 可 以 配置 一 些 可 选 的 属性 参数 来 获得 一 些 不 同 的 功能 ， 比 如 x-message-tt1l、 
x-expires. x-max-length 等 。 通 过 客户 端 设 定 的 这 些 属性 参数 一 旦 设置 成 功 就 不 能 再 改 
变 〈 不 能 修改 也 不 能 添加 )， 除 非 删除 原来 的 交换 器 或 队列 之 后 再 重新 创建 新 的 。 

Policy 的 介入 就 可 以 很 好 的 解决 这 类 问题 , 它 是 一 种 特殊 的 Parameter 的 用 法 .Policy 是 vhost 
级 别 的 。 一 个 Policy 可 以 匹配 一 个 或 者 多 个 队列 〈 或 者 交换 器 ， 或 者 两 者 兼 有 )， 这 样 便于 批量 
管理 。 与 此 同时 ，Policy 也 可 以 支持 动态 地 修改 一 些 属性 参数 ， 大 大 地 提高 了 应 用 的 灵活 度 。 
一 般 来 说 ，Policy 用 来 配置 Federation、 镜 像 、 备 份 交 换 器 、 死 信 等 功能 。 

rabbitmq managemet 插件 本 身 就 提供 了 Policy 的 支持 。 可 以 在 “Admin”->“Policies” 
-> * Add / update a policy” 中 添加 一 个 Policy。 参 考 图 6-1， 包 含 以 下 几 个 参数 。 
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Virtual host: 表示 当前 Policy 所 在 的 vhost 是 哪个 。 
Name: 表示 当前 Policy 的 名 称 。 
Pattern: 一 个 正则 表达 式 ， 用 来 匹配 相关 的 队列 或 者 交换 器 。 


Apply to: 用 来 指定 当前 Policy 作用 于 哪 一 方 。 一 共有 三 个 选项 一 一 “Exchanges and 
queues” 表 示 作 用 与 Pattern 所 匹配 的 所 有 队列 和 交换 器 ;“Exchanges” 表 示 作 用 于 与 
Pattern 所 匹配 的 所 有 交换 器 ;“Queues” 表 示 作 用 于 与 Pattern 所 匹配 的 所 有 队列 。 
信 Priority: 定义 优先 级 。 如 果 有 多 个 Policy 作用 于 同一 个 交换 器 或 者 队列 ， 那 么 
Priority 最 大 的 那个 Policy 才 会 有 用 。 


* Definition: 定义 一 组 或 者 多 组 键 值 对 ， 为 匹配 的 交换 器 或 者 队列 附加 相应 的 功能 。 


9 9 9 9 


v Add / update a policy 


Virtual host: 7 


Name: 


[Sting v | ` 
HA HA mode (?) | HA params (?) | HA sync mode (?) 
Federation Federation upstream set (?) | Federation upstream (?) 


Queues Message TTL | Auto expire | Max length | Max length bytes 
Dead letter exchange | Dead letter routing key | Lazy mode 


Exchanges Alternate exchange 





图 6-1 添加 Policy 


作为 一 种 Paramter, Policy 也 可 以 通过 rabbitmqctl 工具 或 者 HTTP API 接口 来 操作 。 与 
前 面 所 讲 的 Parameter XIM, rabbitmqctl 工具 或 者 HTTP API 接口 各 种 都 有 set、clear 和 list 
的 功能 。 


rabbitmqctl set policy [-p vhost] [--priority priority] [--apply-to apply-to] (name) (pattern) 
(definition) 
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用 来 设置 一 个 Policy。 其 中 的 参数 name. patten 和 definition 是 必 填 项 ， 相 关 的 参 
数 细节 可 以 参考 图 6-1 中 的 参数 。 


示例 如 下 ， 设 置 默认 的 vhost 中 所 有 以 “^amq.” 开 头 的 交换 器 为 联邦 交换 器 ; 


[root@nodel ~]# rabbitmqctl set policy --apply-to exchanges --priority 1 pl 
"^amq." "("federation-upstream":"f1 

Setting policy "pl" for pattern "^amq." to "{\"federation-upstream\":\"f1\"}" 
with priority "1" 


对 应 的 HTTP API 接口 调用 为 : 


[root@nodel ~]# curl -i -u root:root123 -XPUT -d '("pattern": "^amqN.","definition": 
("federation-upstream":"fl"), "priority": 1, "apply-to": "exchanges")' http://192. 
168.0.2:15672/api/policies/$2F/p1l 


HTTP/1.1 204 No Content 

server: Cowboy 

date: Mon, 21 Aug 2017 12:36:20 GMT 
content-length: 0 

content-type: application/json 

vary: accept, accept-encoding, origin 


rabbitmqctl list policies [-p vhost] 


列 出 默认 vhost 中 所 有 的 Policy。 示 例如 下 : 


[root@nodel ~]# rabbitmqctl list policies 
Listing policies 
/ pl exchanges ^amq. ("federation-upstream":"f1"]] 


对 应 的 HTTP API 接口 调用 为 : 


[rootGnodel -]4 curl -i -u root:root123 -XGET http://192.168.0.2:15672/api/ 
policies/$2F 


HTTP/1.1-200 OK 

server: Cowboy 

date: Mon, 21 Aug 2017 12:37:30 GMT 

content-length: 125 

content-type: application/json 

vary: accept, accept-encoding, origin 

Cache-Control: no-cache 

[("vhost":"/","name":"p1","pattern":"^amqNA.", "apply-to":"exchanges","defini 
tion":("federation-upstream":"f1"),"priority":1]] 


rabbitmqctl clear policy [-p vhost] (name) 


清除 指定 的 Policy。 示 例如 下 : 
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[rootenodel ~]# rabbitmqctl clear policy pl 
Clearing policy "pl" 


对 应 的 HTTP API 接口 调用 为 : 


[root@nodel -]4 curl -i -u root:root123 -XDELETE http://192.168.0.2:15672/api/ 
policies/$2F/pl 


HTTP/1.1 204 No Content 

server: Cowboy 

date: Mon, 21 Aug 2017 12:38:55 GMT 
content-length: 0 

content-type: application/json 

vary: accept, accept-encoding, origin 


如 果 两 个 或 多 个 Policy 都 作用 到 同一 个 交换 器 或 者 队列 上 ， 且 这 些 Policy 的 优先 级 都 是 一 
样 的 , 则 参数 项 最 多 的 Policy 具有 决定 权 。 如 果 参 数 一 样 多 , 则 最 后 添加 的 Policy 具有 决定 权 。 
在 第 8 章 的 Federation 和 第 9 章 的 镜像 队列 中 会 有 更 多 关于 Policy 使 用 的 介绍 。 


6.4 小 结 


RabbitMQ 在 配置 这 方面 可 谓 相 当 完 善 , 在 很 多 情况 下 都 可 以 使 用 默认 的 配置 而 不 需要 改变 
其 中 任何 一 个 就 可 以 让 RabbitMQ 很 好 地 提供 服务 .不 过 也 有 一 些 特殊 的 情况 , 比如 默认 的 5672 
端口 被 其 他 的 应 用 程序 所 占用 ,那么 就 需要 修改 环境 变量 RABBITMO NODE PORT 或 者 修改 配 
置 文件 中 的 tcp_1isteners。 如 果 需 要 尽 可 能 地 发 挥 RabbitMQ 本 身 的 性 能 ， 那 么 对 于 配置 
参数 的 调 优 就 显得 至 关 重 要 了 ， 比 如 禁用 Nagle 算法 或 者 增 大 TCP 缓冲 区 的 大 小 可 以 提高 吞吐 
量 ， 更 多 的 细节 等 待 着 读者 慢 慢 地 发 掘 。 
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在 RabbitMQ 使 用 过 程 中 难免 会 出 现 各 式 各 样 的 异常 情况 ， 有 客户 端的 ， 也 有 服务 端的 。 
客户 端的 异常 一 般 是 由 于 应 用 代码 的 缺陷 造成 的 ， 这 个 从 RabbitMQ 本 身 的 角度 无 法 掌控 。 对 
于 服务 端的 异常 (包括 有 一 些 客户 端的 异常 也 是 由 于 RabbitMQ 服务 端的 异常 而 引起 的 ) 来 说 ， 
虽然 不 能 完全 杜绝 ， 但 是 可 以 采取 一 些 有 效 的 手段 去 监测 、 管 控 ， 当 某 些 指标 超过 阔 值 时 能 够 
迅速 采取 一 些 措施 去 修正 ， 以 防止 发 生 不 必要 的 故障 ( 比如 单 点 故障 、 集 群 故障 等 )， 而 当真 正 
发 生 故 障 时 也 要 能 够 迅速 修复 。 
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71 集群 搭建 


在 LA 节 中 , 我们 介绍 了 如 何 安装 及 运行 RabbitMQ 服务 ， 不 过 这 些 是 单机 版 的 ， 无 法 满足 
目前 真实 应 用 的 要 求 。 试 想 一 下 ， 如 果 RabbitMQ 服务 器 遇 到 内 存 裔 溃 、 机 器 掉 电 或 者 主板 故 
障 等 情况 ， 该 怎么 办 ? 单 台 RabbitMQ 服务 器 可 以 满足 每 秒 1000 条 消息 的 吞吐 量 ， 那 么 如 果 应 
用 需要 RabbitMQ 服务 满足 每 秒 10 万 条 消息 的 吞吐 量 呢 ?购买 昂贵 的 服务 器 来 增强 单机 
RabbitMQ 服务 的 性 能 显得 捉襟见肘 ， 搭 建 一 个 RabbitMQ 集群 才 是 解决 实际 问题 的 关键 。 


RabbitMQ 集群 允许 消费 者 和 生产 者 在 RabbitMQ 单个 节点 崩溃 的 情况 下 继续 运行 , 它 可 以 
通过 添加 更 多 的 节点 来 线性 地 扩展 消息 通信 的 吞吐 量 。 当 失去 一 个 RabbitMQ 节点 时 ， 客 户 端 
能 够 重新 连接 到 集群 中 的 任何 其 他 节点 并 继续 生产 或 者 消费 。 


不 过 RabbitMQ 集群 不 能 保证 消息 的 万 无 一 失 ， 即 将 消息 、 队 列 、 交 换 器 等 都 设置 为 可 持 
久 化 ， 生 产 端 和 消费 端 都 正确 地 使 用 了 确认 方式 。 当 集群 中 一 个 RabbitMQ 节点 崩溃 时 ， 该 节 
点 上 的 所 有 队列 中 的 消息 也 会 丢失 。RabbitMQ 集群 中 的 所 有 节点 都 会 备份 所 有 的 元 数据 信息 ， 
包括 以 下 内 容 。 


* 队列 元 数据 : 队列 的 名 称 及 属性 ; 

信 交换 器 : 交换 器 的 名 称 及 属性 ; 

* 绑 定 关系 元 数据 ; 交换 器 与 队列 或 者 交换 器 与 交换 器 之 间 的 绑 定 关系 ; 

9 vhost 元 数据 : 为 vhost 内 的 队列 、 交 换 器 和 绑 定 提 供 命名 空间 及 安全 属性 。 


但 是 不 会 备份 消息 〈 当 然 通过 特殊 的 配置 比如 镜像 队列 可 以 解决 这 个 问题 ， 在 第 9.4 节 中 
会 有 详细 的 介绍 )。 基 于 存储 空间 和 性 能 的 考虑 ， 在 RabbitMQ 集群 中 创建 队列 ， 集 群 只 会 在 单 
个 节点 而 不 是 在 所 有 节点 上 创建 队列 的 进程 并 包含 完整 的 队列 信息 (元 数据 、 状 态 、 内 容 )。 这 
样 只 有 队列 的 宿主 节点 ， 即 所 有 者 节点 知道 队列 的 所 有 信息 ， 所 有 其 他 非 所 有 者 节点 只 知道 队 
列 的 元 数据 和 指向 该 队列 存在 的 那个 节点 的 指针 。 因 此 当 集 群 节点 崩溃 时 ， 该 节点 的 队列 进程 
和 关联 的 绑 定 都 会 消失 。 附 加 在 那些 队列 上 的 消费 者 也 会 丢失 其 所 订阅 的 信息 ， 并 且 任 何 匹 配 
该 队列 绑 定 信息 的 新 消息 也 都 会 消失 。 
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不 同 于 队列 那样 拥有 自己 的 进程 ， 交 换 器 其 实 只 是 一 个 名 称 和 绑 定 列表 。 当 消息 发 布 到 交 
换 器 时 ， 实 际 上 是 由 所 连接 的 信道 将 消息 上 的 路 由 键 同 交换 器 的 绑 定 列表 进行 比较 ， 然 后 再 路 
由 消息 。 当 创建 一 个 新 的 交换 器 时 ，RabbitMQ 所 要 做 的 就 是 将 绑 定 列表 添加 到 集群 中 的 所 有 节 
点 上 。 这 样 ， 每 个 节点 上 的 每 条 信道 都 可 以 访问 到 新 的 交换 器 了 。 


介绍 完 这 些 预 备 知识 ， 就 可 以 切入 本 节 的 正题 了 。 本 节 主 要 介绍 如 何 正确 有 效 地 搭建 一 个 
RabbitMQ 集群 ， 以 便 真正 地 应 用 于 实际 生产 环境 。 本 节 同 样 还 会 介绍 如 何在 单机 上 配置 
RabbitMQ 的 多 实例 集群 ， 以 便 可 以 满足 在 受 限 资源 下 的 集群 测试 应 用 。 


7.1.1 多 机 多 节点 配置 


多 机 多 节点 是 针对 下 一 节 的 单机 多 节点 而 言 的 , 主要 是 指 在 每 台 机 器 中 部 署 一 个 RabbitMQ 
服务 节点 ， 进 而 由 多 台 机 器 组 成 一 个 RabbitMQ 和 集群。 在 配置 集群 之 前 ,需要 根据 LA 节 的 方法 
正确 地 安装 RabbitMQ。 


假设 这 里 一 共有 三 台 物 理 主机 , 均 已 正确 地 安装 了 RabbitMQ, 且 主 机 名 分 别 为 nodel、node2 
和 node3. RabbitMQ 集群 对 延迟 非常 敏感 ， 应 当 只 在 本 地 局 域 网 内 使 用 。 在 广域网 中 不 应 该 使 
用 集群 ， 而 应 该 使 用 Federation 或 者 Shove 来 代替 。 


接 下 来 需要 按照 以 下 步骤 执行 。 第 一 步 ， 配 置 各 个 节点 的 hosts 文件 ， 让 各 个 节点 都 能 互相 
识别 对 方 的 存在 。 比 如 在 Linux 系统 中 可 以 编辑 /etc/hosts 文件 , 在 其 上 添加 IP 地址 与 节点 
名 称 的 映射 信息 : 


192.168.0.2 nodel 
192.168.0.3 node2 
192.168.0.4 node3 


第 二 步 ,编辑 RabbitMQ 的 cookie 文件 , 以 确保 各 个 节点 的 cookie 文件 使 用 的 是 同一 个 值 。 
可 以 读 取 nodel 节点 的 cookie 值 ， 然 后 将 其 复制 到 node2 和 node3 节点 中 。cookie 文件 默认 路 
f /var/lib/rabbitmq/.erlang.cookie 或 者 SHOME/ .erlang.cookie。cookie 相当 
于 密 钥 令 牌 ， 集 群 中 的 RabbitMQ 节点 需要 通过 交换 密 钥 令 牌 以 获得 相互 认证 。 如 果 节 点 的 密 
钥 令 牌 不 一 致 ， 那 么 在 配置 节点 时 就 会 有 如 下 的 报错 ， 注 意 字体 加 粗 部 分 。 


[root@node2 ~]# rabbitmqctl join cluster rabbit@nodel 
Clustering node rabbit@node2 with rabbit@nodel 
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Error: unable to connect to nodes [rabbit8nodel]: nodedown 


DIAGNOSTICS 


attempted to contact: [rabbit@nodel] 


rabbit8nodel: 

* connected to epmd (port 4369) on nodel 

* epmd reports node 'rabbit' running on port 25672 

* TCP connection succeeded but Erlang distribution failed 


* Authentication failed (rejected by the remote node), please check the Erlang 
cookie 


current node details: 

- node name: 'rabbitmq-cli-53Gnode2' 

- home dir: /root 

- cookie hash: kLtTY75JJGZnZpQF7CqnYg-- 


第 三 步 ， 配 置 集群 。 配 置 集群 有 三 种 方式 : 通过 rabbitmqctl 工具 配置 通过 
rabbitmq.config 配置 文件 配置 ， 通 过 rabbitmg-autocluster' 插件 配置 。 这 里 主要 讲 
的 是 通过 rabbitmqctl 工具 的 方式 配置 集群 ， 这 种 方式 也 是 最 常用 的 方式 。 其 余 两 种 方式 在 
实际 应 用 中 用 之 其 少 ， 所 以 不 多 做 介绍 。 


首先 启动 nodel、node2 和 node3 这 3 个 节点 的 RabbitMQ 服务 。 


[root@nodel ~]# rabbitmq-server -detached 
[root@node2 ~]# rabbitmq-server -detached 
[root@node3 ~]# rabbitmq-server -detached 


这 样 ， 这 3 个 节点 目前 都 是 以 独立 节点 存在 的 单个 集群 。 通 过 rabbitmqctl cluster_ 
status 命令 来 查看 各 个 节点 的 状态 。 


[root@nodel ~]# rabbitmqctl cluster status 
Cluster status of node rabbit@nodel 
[(nodes, [(disc, [rabbit8nodel])]]), 
(running nodes, [rabbit8nodel]], 
(cluster name,««"rabbit8(nodel"»»], 
(partitions, []), 
(alarms,[(rabbit8nodel,[1)1)] 
[root(node2 ~]# rabbitmqctl cluster status 
Cluster status of node rabbitG8node2 


l https://github.com/aweber/rabbitmq-autocluster/。 
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[(nodes, [(disc,[rabbit8node2])]]), 
(running nodes, [rabbit8node2]], 
(cluster name,««"rabbit8node2"»2], 
(partitions, [1], 

(alarms, [(rabbit8node2,[])])] 
[root@node3 ~]# rabbitmqctl cluster status 
Cluster status of node rabbitünode3 
[(nodes, [(disc, [rabbit8node3])]), 

(running nodes, [rabbit8node3]], 

(cluster name,««"rabbit8ünode3"»»], 

(partitions, []), 

(alarms,[(rabbitG8node3,[])1)] 


接 下 来 为 了 将 3 个 节点 组 成 一 个 集群 ， 需 要 以 nodel 节点 为 基准 ， 将 node2 和 node3 节点 
加 入 nodel 节点 的 集群 中 。 这 3 个 节点 是 平等 的 ， 如 果 想 调换 彼此 的 加 入 顺序 也 未 尝 不 可 。 首 
先 将 node2 节点 加 入 nodel 节点 的 集群 中 ， 需 要 执行 如 下 4 个 命令 步骤 。 


[root@node2 ~]# rabbitmqctl stop app 

Stopping rabbit application on node rabbit8node2 
[root@node2 ~]# rabbitmqctl reset 

Resetting node rabbitG8node2 

[root8node2 ~]# rabbitmqctl join cluster rabbit68nodel 
Clustering node rabbitG8node2 with rabbitünodel 
[rooténode2 ~]# rabbitmqctl start app 

Starting node rabbitG8node2 


如 此 ，nodel 节点 和 node2 节点 便 处 于 同一 个 集群 之 中 ， 我 们 在 这 两 个 节点 上 都 执行 
rabbitmqctl cluster status 命令 可 以 看 到 同样 的 输出 。 


[(nodes, [ (disc, [rabbit@node1l, rabbit@node2]}]}, 
(running nodes, [rabbit68nodel,rabbit68node2]], 
(cluster name,««"rabbit8nodel"»»], 
(partitions, []1), 

(alarms,[í(rabbitG8nodel, []),(rabbitQnode2,[]1])1])] 


最 后 将 node3 节点 也 加 入 nodel 节点 所 在 的 集群 中 ， 这 3 个 节点 组 成 了 一 个 完整 的 集群 。 
在 任意 一 个 节点 中 都 可 以 看 到 如 下 的 集群 状态 。 


[(nodes, [(disc, [rabbit8nodel,rabbit8node2,rabbit8node3]]]), 
(running nodes, [rabbit nodel, rabbit8node2,rabbitQ8node3]], 

(cluster name,««"rabbit8ünodel"»»), 

(partitions, [])], 

(alarms, [(rabbitG8nodel, []), (rabbitG8node2,[]) ,(rabbitGnode3, [])1)] 


现在 已 经 完成 了 集群 的 搭建 。 如 果 集 群 中 某 个 节点 关闭 了 , 那么 集群 会 处 于 什么 样 的 状态 ? 
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这 里 我 们 在 node2 节点 上 执行 rabbitmqctl stop app 命令 来 主动 关闭 RabbitMQ 应 用 。 此 
时 在 nodel 上 看 到 的 集群 状态 可 以 参考 下 方 信 息 ， 可 以 看 到 在 running nodes 这 一 选项 中 已 
经 没有 了 rabbit@node2 这 一 节点 。 


[(nodes, [(disc, [rabbit@nodel, rabbit@node2, rabbit@node3]}]}, 
(running nodes, [rabbit@nodel ,rabbit@node3]}, 

(cluster name,««"rabbit8nodel"»»], 

(partitions, []), 

(alarms,[(rabbitGnodel,[]) , {rabbit@node3,[]}]}] 


如 果 关 闭 了 集群 中 的 所 有 节点 ， 则 需要 确保 在 启动 的 时 候 最 后 关闭 的 那个 节点 是 第 一 个 启 
动 的 。 如 果 第 一 个 启动 的 不 是 最 后 关闭 的 节点 ， 那 么 这 个 节点 会 等 待 最 后 关闭 的 节点 启动 。 这 
个 等 待 时 间 是 30 秒 ， 如 果 没 有 等 到 ， 那 么 这 个 先 启动 的 节点 也 会 失败 。 在 最 新 的 版 本 中 会 有 重 
试 机 制 ， 默 认 重 试 10 次 30 秒 以 等 待 最 后 关闭 的 节点 启动 。 


=INFO REPORT==== 23-Jul-2017::12:08:10 === 
Waiting for Mnesia tables for 30000 ms, 9 retries left 


=WARNING REPORT==== 23-Jul-2017::12:08:40 === 

Error while waiting for Mnesia tables: {timeout waiting for tables, 
[rabbit user,rabbit user permission, 
rabbit vhost,rabbit durable route, 
rabbit durable exchange, 
rabbit runtime parameters, 
rabbit durable queue]) 


在 重 试 失败 之 后 ， 当 前 节点 也 会 因 失败 而 关闭 自身 的 应 用 。 比 如 nodel 节点 最 后 关闭 ， 那 
么 此 时 先 启动 node2 节点 ， 在 等 待 若干 时 间 之 后 发 现 nodel 还 是 没有 启动 ， 则 会 有 如 下 报错 : 


BOOT FAILED 


Timeout contacting cluster nodes: [rabbit@nodel]. 


BACKGROUND 


This cluster node was shut down while other nodes were still running. 
To avoid losing data, you should start the other nodes first, then 
start this one. To force this node to start, first invoke 
"rabbitmqctl force boot". If you do so, any changes made on other 
cluster nodes after this one was shut down may be lost. 


DIAGNOSTICS 
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attempted to contact: [rabbit@nodell] 


rabbitünodel: 
* connected to epmd (port 4369) on nodel 
* node rabbit6nodel up, 'rabbit' application not running 
* running applications on rabbit68nodel: [inets,ranch,ssl,public key,crypto, 
syntax tools,compiler,asnl,xmerl, 
sasl,stdlib,kernel] 
* suggestion: start app on rabbitG8nodel 


current node details: 

- node name: rabbit(8node2 

- home dir: /root 

- cookie hash: VCwbL3S9/ydrGgVsrLjVkA-- 


Error: timeout waiting for tables 


如 果 最 后 一 个 关闭 的 节点 最 终 由 于 某 些 异常 而 无 法 启动 ， 则 可 以 通过 rabbitmqctl 
forget cluster node 命令 来 将 此 节点 剔 出 当前 集群 ， 详 细 内 容 可 以 参考 7.1.3 节 。 如 果 集 
群 中 的 所 有 节点 由 于 某 些 非 正常 因素 ， 比 如 断 电 而 关闭 ， 那 么 集群 中 的 节点 都 会 认为 还 有 其 他 
节点 在 它 后 面 关 闭 ， 此 时 需要 调用 rabbitmqctl force boot 命令 来 启动 一 个 节点 ， 之 后 
集群 才能 正常 启动 。 


[root@node2 ~]# rabbitmqctl force boot 
Forcing boot for Mnesia dir /opt/rabbitmq/var/lib/rabbitmq/mnesia/rabbit(node2 
[root@node2 ~]# rabbitmq-server -detached 


7.1.2 ”集群 节点 类 型 


在 使 用 rabbitmqctl cluster status 命令 来 查看 集群 状态 时 会 有 {nodes, [ (disc, 
[rabbit@nodel,rabbit@node2,rabbit@node3] }] 这 一 项 信息 ， 其 中 的 disc 标注 了 
RabbitMQ 节点 的 类 型 。RabbitMQ 中 的 每 一 个 节点 ， 不 管 是 单一 节点 系统 或 者 是 集群 中 的 一 部 分 ， 
要 么 是 内 存 节点 , 要 么 是 磁盘 节点 。 内 存 节点 将 所 有 的 队列 、 交 换 器 、 绑 定 关系 、 用 户 、 权 限 和 vhost 
的 元 数据 定义 都 存储 在 内 存 中 ， 而 磁盘 节点 则 将 这 些 信息 存储 到 磁盘 中 。 单 节点 的 集群 中 必然 只 有 
磁盘 类 型 的 节点 , 否则 当 重 启 RabbitMQ 之 后 , 所 有 关于 系统 的 配置 信息 都 会 丢失 。 不 过 在 集群 中 ， 
可 以 选择 配置 部 分 节点 为 内 存 节点 ， 这 样 可 以 获得 更 高 的 性 能 。 
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比如 将 node2 节点 加 入 nodel 节点 的 时 候 可 以 指定 node2 节点 的 类 型 为 内 存 节 点 。 


[root@node2 ~]# rabbitmqctl join cluster rabbit68nodel --ram 
Clustering node rabbit8node2 with rabbitü8nodel 


这 样 在 以 nodel 和 node2 组 成 的 集群 中 就 会 有 一 个 磁盘 节点 和 一 个 内 存 节 点 ， 可 以 参考 下 
面 的 打印 信息 。 默 认 不 添加 “--zam” 参 数 则 表示 此 节点 为 磁盘 节点 。 


[root@node2 ~]# rabbitmqctl cluster status 

Cluster status of node rabbit8node2 

[(nodes, [(disc, [rabbitQGnodel]), (ram, [rabbit8node2])]]]), 
(running nodes, [rabbit nodel, rabbitQ8node2]], 

(cluster name,««"rabbit8nodel"»»], 

(partitions,[]), 

(alarms,[(rabbitG8nodel, []),(rabbit8node2,[1)1)] 


如 果 集 群 已 经 搭建 好 了 , 那么 也 可 以 使 用 rabbitmqctl change cluster node type 
{disc, ram 命令 来 切换 节点 的 类 型 , 其 中 disc 表示 磁盘 节点 , 而 ram 表示 内 存 节点 。 举 例 ， 
这 里 将 上 面 node2 节点 由 内 存 节点 转变 为 磁盘 节点 。 


[root(node2 ~]# rabbitmqctl stop app 

Stopping rabbit application on node rabbit8node2 
[root@node2 -]4 rabbitmqctl change cluster node type disc 
Turning rabbit8node2 into a disc node 
[root(node2 ~]# rabbitmqctl start app 

Starting node rabbit@node2 

[root(node2 ~]# rabbitmqctl cluster status 
Cluster status of node rabbit(node2 

[ (nodes, [(disc, [rabbitG8nodel,rabbit8(node2])]]), 
(running nodes, [rabbitG8nodel,rabbit8node2]], 
(cluster name,««"rabbitünodel"»»5], 
(partitions, []], 

(alarms,[(rabbit8nodel, []),(rabbit8node2,[1)1)] 


在 集群 中 创建 队列 、 交 换 器 或 者 绑 定 关 系 的 时 候 ， 这 些 操 作 直 到 所 有 集群 节点 都 成 功 提交 
元 数据 变更 后 才 会 返回 。 对 内 存 节 点 来 说 ， 这 意味 着 将 变更 写 入 内 存 ， 而 对 于 磁盘 节点 来 说 ， 
这 意味 着 昂贵 的 磁盘 写 入 操作 。 内 存 节 点 可 以 提供 出 色 的 性 能 ， 磁 盘 节 点 能 够 保证 集群 配置 信 
息 的 高 可 靠 性 ， 如 何在 这 两 者 之 间 进 行 抉 择 呢 ? 

RabbitMQ 只 要 求 在 集群 中 至 少 有 一 个 磁盘 节点 , 所 有 其 他 节点 可 以 是 内 存 节点 。 当 节点 加 
入 或 者 离开 集群 时 ， 它 们 必须 将 变更 通知 到 至 少 一 个 磁盘 节点 。 如 果 只 有 一 个 磁盘 节点 ， 而 且 
不 凑巧 的 是 它 刚 好 月 演 了 ， 那 么 集群 可 以 继续 发 送 或 者 接收 消息 ， 但 是 不 能 执行 创建 队列 、 交 
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换 器 、 绑 定 关 系 、 用 户 ， 以 及 更 改 权限 、 添 加 或 删除 集群 节点 的 操作 了 。 也 就 是 说 ， 如 果 集 群 
中 唯一 的 磁盘 节点 崩 演 ， 和 集群 仍 然 可 以 保持 运行 ， 但 是 直到 将 该 节点 恢复 到 集群 前 ， 你 无 法 更 
改 任何 东西 。 所 以 在 建立 集群 的 时 候 应 该 保证 有 两 个 或 者 多 个 磁盘 节点 的 存在 。 


在 内 存 节 点 重启 后 ， 它 们 会 连接 到 预先 配置 的 磁盘 节点 ， 下 载 当前 集群 元 数据 的 副本 。 当 
在 集群 中 添加 内 存 节点 时 ， 确 保 告知 其 所 有 的 磁盘 节点 (内 存 节点 唯一 存储 到 磁盘 的 元 数据 信 
息 是 集群 中 磁盘 节点 的 地 址 )。 只 要 内 存 节点 可 以 找到 至 少 一 个 磁盘 节点 , 那么 它 就 能 在 重启 后 
重新 加 入 集群 中 。 


除非 使 用 的 是 RabbitMQ 的 RPC 功能 , 否则 创建 队列 交换 器 及 绑 定 关系 的 操作 确 是 甚 少 ， 
大 多 数 的 操作 就 是 生产 或 者 消费 消息 。 为 了 确保 集群 信息 的 可 靠 性 ， 或 者 在 不 确定 使 用 磁盘 节 
点 或 者 内 存 节点 的 时 候 ， 建 议 全 部 使 用 磁盘 节点 。 


7.13 ”剔除 单个 节点 


创建 集群 的 过 程 可 以 看 作 向 集群 中 添加 节点 的 过 程 。 那么 如 何 将 一 个 节点 从 集群 中 剔除 呢 ? 
这 样 可 以 让 集群 规模 变 小 以 节省 硬件 资源 , 或 者 蔡 换 一 个 机 器 性 能 更 好 的 节点 。 同样 以 nodel、 
node2 和 node3 组 成 的 集群 为 例 ， 这 里 有 两 种 方式 将 node2 剥离 出 当前 集群 。 


第 一 种 ， 首 先 在 node2 节点 上 执行 rabbitmqctl stop_app 或 者 rabbitmqctl stop 
命令 来 关闭 RabbitMQ 服务 。 之 后 再 在 nodel 节点 或 者 node3 节点 上 执行 rabbitmqctl 
forget cluster node rabbitenode2 命令 将 nodel 节点 剔除 出 去 。 这 种 方式 适合 node2 
节点 不 再 运行 RabbitMQ 的 情况 。 


[root@nodel ~]# rabbitmqctl forget cluster node rabbit8node2 
Removing node rabbitG8node2 from cluster 


在 前 面 7.1.1 节 中 提 到 , 在 关闭 集群 中 的 每 个 节点 之 后 ， 如 果 最 后 一 个 关闭 的 节点 最 终 由 于 
某 些 异常 而 无 法 启动 ， 则 可 以 通过 rabbitmqctl forget cluster node 命令 来 将 此 节点 
剔除 出 当前 集群 。 举 例 ， 集 群 中 节点 按照 node3、node2、nodel 的 顺序 关闭 ， 此 时 如 果 要 启动 
集群 ， 就 要 先 启动 nodel 节点 。 


[root@node3 ~]# rabbitmqctl stop 
Stopping and halting node rabbit@node3 
[root@node2 ~]# rabbitmqctl stop 
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Stopping and halting node rabbit(node2 
[root@nodel ~]# rabbitmqctl stop 
Stopping and halting node rabbitGnodel 


这 里 可 以 在 node2 节点 中 执行 命令 将 nodel 节点 剔除 出 当前 集群 。 


[root(node2 ~]# rabbitmqctl forget cluster node rabbit@nodel -offline 
Removing node rabbitG6nodel from cluster 

* Impersonating node: rabbitG86node2... done 

* Mnesia directory : /opt/rabbitmqg/var/lib/rabbitmg/mnesia/rabbit(node2 


[root@node2 ~]# rabbitmq-server -detached 
Warning: PID file not written; -detached was passed. 


[root(node2 ~]# rabbitmqctl cluster status 
Cluster status of node rabbitGnode2 

[(nodes, [(disc, [rabbitGnode2,rabbit8node3])]), 
(running nodes, [rabbit8node2]], 

(cluster name,««"rabbit8nodel"»»], 
(partitions,[]), 

(alarms,[(rabbit8node2,[])1])] 


注意 上 面 在 使 用 rabbitmqctl forget cluster node 命令 的 时 候 用 到 了 
“--offline” 参 数 ， 如 果 不 添 加 这 个 参数 ， 就 需要 保证 node2 节点 中 的 RabbitMQ 服务 处 于 
运行 状态 ， 而 在 这 种 情况 下 ，node2 无 法 先行 启动 ， 则 “--offline” 参 数 的 添加 让 其 可 以 在 
非 运行 状态 下 将 nodel 剥离 出 当前 集群 。 


第 二 种 方式 是 在 node2 上 执行 rabbitmqctl reset 命令 。 如 果 不 是 像 上 面 由 于 启动 顺 
序 的 缘故 而 不 得 不 删除 一 个 集群 节点 ， 建 议 采 用 这 种 方式 。 


[rootünode2 ~]# rabbitmqctl stop app 

Stopping rabbit application on node rabbitnode2 
[root@node2 ~]# rabbitmqctl reset 

Resetting node rabbit@node2 

[root(node2 ~]# rabbitmqctl start app 

Starting node rabbitG8node2 


如 果 从 node2 节点 上 检查 集群 的 状态 ， 会 发 现 它 现在 是 独立 的 节点 。 同 样 在 集群 中 剩余 的 
节点 nodel 和 node3 上 看 到 node2 已 不 再 是 集群 中 的 一 部 分 了 。 


正如 之 前 所 说 的 , rabbitmqctl1 reset 命令 将 清空 节点 的 状态 , 并 将 其 恢复 到 空白 状态 。 
当 重 设 的 节点 是 集群 中 的 一 部 分 时 ， 该 命令 也 会 和 集群 中 的 磁盘 节点 进行 通信 ， 告 诉 它们 该 节 
点 正在 离开 集群 。 不 然 集 群 会 认为 该 节点 出 了 故障 ， 并 期 望 其 最 终 能 够 恢复 过 来 。 
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7.1.4 ”集群 节点 的 升级 


如 果 RabbitMQ 集群 由 单独 的 一 个 节点 组 成 , 那么 升级 版 本 很 容易 , 只 需 关闭 原来 的 服务 ， 
然后 解压 新 的 版 本 再 运行 即 可 。 不 过 要 确保 原 节 点 的 Mnesia 中 的 数据 不 被 变更 ， 且 新 节点 中 的 
Mnesia 路 径 的 指向 要 与 原 节点 中 的 相同 。 或 者 说 保留 原 节点 Mnesia 数据 ， 然 后 解压 新 版 本 到 
相应 的 目录 ， 再 将 新 版 本 的 Mnesia 路 径 指向 保留 的 Mnesia 数据 的 路 径 〈 也 可 以 直接 复制 保留 
的 Mnesia 数据 到 新 版 本 中 相应 的 目录 )， 最 后 启动 新 版 本 的 服务 即 可 。 


如 果 RabbitMQ 集群 由 多 个 节点 组 成 ， 那 么 也 可 以 参考 单个 节点 的 情形 。 具 体 步 又 : 
(OD 关闭 所 有 节点 的 服务 ， 注 意 采 用 rabbitmqctl stop 命令 关闭 。 

(20 保存 各 个 节点 的 Mnesia 数据 。 

(3) 解压 新 版 本 的 RabbitMQ 到 指定 的 目录 。 

(4) 指定 新 版 本 的 Mnesia 路 径 为 步骤 2 中 保存 的 Mnesia 数据 路 径 。 

C50 启动 新 版 本 的 服务 ， 注 意 先 重 启 原版 本 中 最 后 关闭 的 那个 节点 。 


其 中 步骤 4 和 步骤 5 可 以 一 起 操作 , 比如 执行 RABBITMO MNESIA BASE-/opt/mnesia 
rabbitmq-server -detached 命令 ,其 中 /opt/mnesia 为 原版 本 保存 Mnesia 数据 的 路 径 。 


RabbitMQ 的 版 本 有 很 多 , 难免 会 有 数据 格式 不 兼容 的 现象 ,这 个 缺陷 在 越 旧 的 版 本 中 越发 
凸显 ， 所 以 在 对 不 同 版 本 升级 的 过 程 中 ， 最 好 先 测试 两 个 版 本 互通 的 可 能 性 ， 然 后 再 在 线 上 环 
境 中 实地 操作 。 

如 果 原 集群 上 的 配置 和 数据 都 可 以 舍弃 ， 则 可 以 删除 原版 本 的 RabbitMQ, 然后 再 重新 安装 
配置 即 可 ; 如 果 配 置 和 数据 不 可 丢弃 ， 则 按照 7.4.1 节 所 述 保存 元 数据 ,之 后 再 关闭 所 有 生产 者 
并 等 待 消费 者 消费 完 队列 中 的 所 有 数据 ， 紧 接着 关闭 所 有 消费 者 ， 然 后 重新 安装 RabbitMQ 并 
重建 元 数据 等 。 


当然 如 果 有 个 新 版 本 的 集群 ， 那 么 从 旧版 本 迁移 到 新 版 本 的 集群 中 也 不 失 为 一 个 升级 的 好 
办 法 ， 集 群 的 迁移 可 以 参考 7.4 节 。 
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7.4.5 单机 多 节点 配置 


由 于 某 些 因素 的 限制 ， 有 时 候 不 得 不 在 单 台 物理 机 器 上 去 创建 一 个 多 RabbitMQ 服务 节点 
的 集群 。 或 者 只 想 要 实验 性 地 验证 集群 的 某 些 特性 ， 也 不 需要 浪费 过 多 的 物理 机 器 去 实现 。 


在 一 台 机 器 上 部 署 多 个 RabbitMQ 服务 节点 ， 需 要 确保 每 个 节点 都 有 独立 的 名 称 、 数 据 存 


储 位 置 、 端 口号 (包括 插件 的 端口 号 ) 


等 。 我 们 在 主机 名 称 为 nodel 的 机 器 上 创建 一 个 由 


rabbitl(gnodel. rabbit2(gnodel 和 rabbit3@nodel 这 3 个 节点 组 成 RabbitMQ 集群 。 


首先 需要 确保 机 器 上 已 经 安装 了 Erlang 和 RabbitMQ 的 程序 。 其 次 ， 为 每 个 RabbitMQ 服 
务 节点 设置 不 同 的 端口 号 和 节点 名 称 来 启动 相应 的 服务 。 


[rootünodel ~]# RABBITMQ NODE PORT-5672 RABBITMQ NODENAME=rabbit1 


rabbitmq-server -detached 


[root@nodel ~]# RABBITMO NODE PORT-5673 RABBITMQ NODENAME-rabbit2 


rabbitmq-server -detached 


[root@nodel ~]# RABBITMO NODE PORT-5674 RABBITMQ NODENAME-rabbit3 


rabbitmq-server -detached 


在 启动 rabbitl@nodel 节点 的 服务 之 后 , 继续 启动 rabbit2@nodel 和 rabbit@nodel 服务 节点 
会 遇 到 启动 失败 的 情况 。 这 种 情况 大 多 数 是 由 于 配置 发 生 了 冲突 而 造成 后 面 的 服务 节点 启动 失 
败 ， 需 要 进一步 确认 是 否 开 启 了 某 些 功能 ， 比 如 RabbitMQ Management 插件 。 如 果 开 启 了 
RabbitMQ Management 插件 ， 就 需要 为 每 个 服务 节点 配置 一 个 对 应 插件 端口 号 ， 具 体内 容 如 下 


所 示 。 


[root@nodel ~]# RABBITMO NODE PORT-5672 RABBITMQ NODENAME-rabbiti 
RABBITMQ SERVER START ARGS-"-rabbitmq management listener [(port,15672)]" 


rabbitmq-server -detached 


[rooténodel ~]# RABBITMQ NODE PORT-5673 RABBITMQ NODENAME-rabbit2 
RABBITMQ SERVER START ARGS-"-rabbitmq management listener [í(port,15673]]" 


rabbitmq-server -detached 


[root@nodel ~]# RABBITMQ NODE PORT-5674 RABBITMQ NODENAME-rabbit3 
RABBITMQ SERVER START ARGS-"-rabbitmq management listener [(port,15674]]" 


rabbitmq-server -detached 


启动 各 节点 服务 之 后 ， 将 rabbit2(2nodel 节点 加 入 rabbitl(gnodel 的 集群 之 中 : 


[root@nodel ~]# rabbitmqctl -n 
Stopping rabbit application on 
[rooténodel ~]# rabbitmqctl -n 
Resetting node rabbit2Gnodel 

[root8nodel ~]# rabbitmqctl -n 


rabbit28nodel stop app 
node rabbit28nodel 
rabbit20nodel reset 


rabbit20nodel join cluster rabbitl8nodel 
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Clustering node rabbit20nodel with rabbitl8nodel 
[root@nodel ~]# rabbitmqctl -n rabbit280nodel start app 
Starting node rabbit28nodel 


紧 接 着 可 以 执行 相似 的 操作 将 rabbit3@nodel 也 加 入 进来 。 最 后 通过 rabbitmqctl 
cluster status 命令 来 查看 各 个 服务 节点 的 集群 状态 : 


[root@nodel ~]# rabbitmqctl -n rabbitl@nodel cluster status 

Cluster status of node rabbitl(nodel 

[(nodes, [ (disc, [rabbitlGnodel,rabbit2Qnodel,rabbit30nodel]]]), 
(running nodes, [rabbit3Gnodel, rabbit2Q80nodel,rabbitl8nodel]], 
(cluster name,««"rabbitl8nodel"»»], 

(partitions,[]), 

(alarms, [(rabbit3Qnodel,[]),(rabbit2Qnodel, []), (rabbitlGnodel, []}]}] 
[rootenodel ~]# rabbitmqctl -n rabbit28nodel cluster status 

Cluster status of node rabbit28nodel 

[(nodes, [(disc, [rabbitlGnodel,rabbit20nodel,rabbit30nodel])]), 
(running nodes, [rabbit38nodel, rabbitlG8nodel,rabbit28nodel]], 
(cluster name,««"rabbitl8nodel"»»], 

(partitions,[]), 
(alarms,[(rabbit3Qnodel,[]),(rabbitiQnodel,[]),(rabbit280nodel, []1)])] 
[root(nodel ~]# rabbitmqctl -n rabbit38nodel cluster status 

Cluster status of node rabbit38nodel 

[(nodes, [(disc, [rabbitl8nodel,rabbit2Qnodel,rabbit38nodel])]), 
(running nodes, [rabbitl8nodel, rabbit20nodel,rabbit38nodel]), 
(cluster name,««"rabbitl8nodel"»»], 

(partitions, []), 
(alarms,[(rabbitlQGnodel,[]),(rabbit2Qnodel, []), (rabbit3G8nodel, [1)])] 


RabbitMQ 的 单机 多 节点 配置 大 多 用 于 实验 性 论证 ， 如果 需 要 在 真实 生产 环境 中 使 用 ,最 好 
还 是 参考 7.1.2 节 搭 建 一 个 多 机 多 节点 的 集群 。 搭 建 集群 不 仅 可 以 扩容 ， 也 能 有 效 地 进行 容 灾 。 


7.2 ”查看 服务 日 志 


如 果 在 使 用 RabbitMQ 的 过 程 中 出 现 了 异常 情况 , 通过 翻阅 RabbitMQ 的 服务 日 志 可 以 让 你 
在 处 理 异常 的 过 程 中 事半功倍 。 RabbitMQ 日 志 中 包含 各 种 类 型 的 事件 ， 比 如 连接 尝试 、 服 务 启 
动 、 插 件 安装 及 解析 请 求 时 的 错误 等 。 本 节 首 先 举 几 个 例子 来 展示 一 下 RabbitMQ 服务 日 志 的 
内 容 和 日 志 的 等 级 ， 接 着 再 来 阐述 如 何 通 过 程序 化 的 方式 来 获得 日 志 及 对 服务 日 志 的 监控 。 
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RabbitMQ 的 日 志 默 认 存 放 在 SRABBITMO HOME/var/1og/rabbitmq 文件 夹 内 。 在 这 个 
文件 夹 内 RabbitMQ 会 创建 两 个 日 志文 件 : RABBITMO NODENAME-sasl.log 和 
RABBITMQ NODENAME . 1og。 


SASL (System Application Support Libraries， 系 统 应 用 程序 支持 库 ) 是 库 的 集合 ， 作 为 
Erlang-OTP 发 行 版 的 一 部 分 。 它 们 帮助 开发 者 在 开发 Erlang 应 用 程序 时 提供 一 系列 标准 ， 其 中 
之 一 是 日 志 记 录 格 式 。 所 以 当 RabbitMQ 记录 Erlang 相关 信息 时 ， 它 会 将 日 志 写 入 文件 
RABBITMQ NODENAME-sasl.log 中 。 举 例 来 说 ,可 以 在 这 个 文件 中 找到 Erlang 的 朋 江 报告 ， 
有 助 于 调试 无 法 启动 的 RabbitMQ 节点 。 


如 果 想 查看 RabbitMQ 应 用 服务 的 日 志 ， 则 需要 查阅 RABBITMO NODENAME . log 这 个 文 
件 ， 所 谓 的 RabbitMQ 服务 日 志 指 的 就 是 这 个 文件 。 


各 位 读者 实际 使 用 的 RabbitMQ 版 本 各 有 差异 ， 这 里 我 们 挑选 一 个 稍 旧版 本 (3.6.2) 来 统 
筹 说 明 ， 以 期 不 会 有 太 大 的 偏差 。 所 幸 各 个 版 本 的 日 志 大 致 相同 ， 只 是 有 略微 变化 。 读 者 需要 
培养 一 种 使 用 服务 日 志 来 解决 问题 的 思路 ， 本 节 只 做 抛砖引玉 之 用 。 


1. 启动 RabbitMQ 服务 


启动 RabbitMQ 服务 可 以 使 用 rabbitmq-server -detached 命令 ， 这 个 命令 会 顺带 启 
动 Erlang 虚拟 机 和 RabbitMQ 应 用 服务 ， 而 rabbitmqctl start app 用 来 启动 RabbitMQ 
应 用 服务 。 注 意 ，RabbitMQ 应 用 服务 启动 的 前 提 是 Erlang 虚拟 机 是 运转 正常 的 。 首 先 来 看 一 
下 在 执行 完 rabbitmq-server -detached 命令 后 其 相应 的 服务 日 志 是 什么 。 


Starting RabbitMQ 3.6.2 on Erlang 19.1 
Copyright (C) 2007-2016 Pivotal Software, Inc. 
Licensed under the MPL. See http://www.rabbitmq.com/ 


-INFO REPORT---- 3-0ct-2017::10:52:08 === 

node : rabbit nodel 

home dir : /root 

config file(s) : /opt/rabbitmq/etc/rabbitmq/rabbitmq.config (not found) 
cookie hash : VCwbL3S9/ydrGgVsrLjVkA-- 

log : /opt/rabbitmqg/var/log/rabbitmq/rabbit6nodel.log 

sasl log : /opt/rabbitmqg/var/log/rabbitmqg/rabbit8nodel-sasl.log 
database dir : /opt/rabbitmq/var/lib/rabbitmqg/mnesia/rabbitG8nodel 


-INFO REPORT---- 3- Oct -2017::10:52:09 === 


e 165 o 


RabbitMQ 实战 指南 


Memory limit set to 3148MB of 7872MB total. 


-INFO REPORT---- 3- Oct -2017::10:52:09 === 
Disk free limit set to 50MB 


-INFO REPORT---- 3- Oct -2017::10:52:09 --- 
Limiting to approx 924 file handles (829 sockets) 


-INFO REPORT---- 3- Oct -2017::10:52:09 
FHC read buffering: OFF 
FHC write buffering: ON 


-INFO REPORT---- 3- Oct -2017::10:52:09 === 
Database directory at /opt/rabbitmqg/var/lib/rabbitmg/mnesia/rabbit8(nodel is 
empty. Initialising from scratch... 


-INFO REPORT---- 3- Oct -2017::10:52:10 === 
Priority queues enabled, real BQ is rabbit variable queue 


-INFO REPORT---- 3- Oct -2017::10:52:10 === 
Adding vhost '/' 


-INFO REPORT---- 3- Oct -2017::10:52:10 === 
Creating user 'guest' 
-INFO REPORT---- 3- Oct -2017::10:52:10 === 


Setting user tags for user 'guest' to [administrator] 


-INFO REPORT-2--- 3- Oct -2017::10:52:10 === 
Setting permissions for '!guest' in WA to '.*', ',*', f, 
-INFO REPORT---- 3- Oct -2017::10:52:10 === 


msg store transient: using rabbit msg store ets index to provide index 


=INFO REPORT==== 3- Oct -2017::10:52:10 === 
msg store persistent: using rabbit msg store ets index to provide index 


-WARNING REPORT---- 3- Oct -2017::10:52:10 === 
msg store persistent: rebuilding indices from scratch 


-INFO REPORT---- 3- Oct -2017::10:52:10 === 
started TCP Listener on [::]:5672 


-INFO REPORT---- 3- Oct -2017::10:52:10 === 
Server startup complete; 0 plugins started. 


这 段 日 志 包含 了 RabbitMQ 的 版 本 号 、Erlang 的 版 本 号 、RabbitMQ 服务 节点 名 称 、cookie 
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的 hash 值 、RabbitMQ 配置 文件 地 址 、 内 存 限 制 、 磁 盘 限 制 、 默 认 账 户 guest 的 创建 及 权限 配置 
等 。 


注意 到 上 面 日 志 中 有 “WARNING REPORT" f “INFO REPORT” 这 些 字样 ， 有 过 编程 经 
验 的 读者 应 该 可 以 猜 出 这 与 日 志 级 别 有 关 。 在 RabbitMQ F, 日 志 级 别 有 none. error. warning. 
info». debug iX 5 种 ， 下 一 层级 别 的 日 志 输 出 均 包 含 上 一 层级 别 的 日 志 输出 ， 比 如 warning 级 别 
的 日 志 包 含 warning 和 error 级 别 的 日 志 ，none 表示 不 输出 日 志 。 日 志 级 别 可 以 通过 
rabbitmq.config 配置 文件 中 的 1og_levels 参数 来 进行 设置 ， 默 认为 [{connection， 
info)] ,详细 内 容 可 参考 第 62 节 。 


如 果 开 启 了 RabbitMQ Management 插件 ， 则 在 启动 RabbitMQ 的 时 候 会 多 打印 一 些 
HE: 


-INFO REPORT---- 3- Oct -2017::10:57:05 === 
Server startup complete; 6 plugins started. 
rabbitmq management 

rabbitmq management agent 
rabbitmq web dispatch 

webmachine 

mochiweb 

amqp client 


当然 还 包括 一 些 统计 值 信息 的 初始 化 日 志 ， 类 似 如 下 : 


* 


E X* * X* 


-INFO REPORT---- 3- Oct -2017::10:57:05 === 
Statistics garbage collector started for table (aggr queue stats fine stats, 
5000). 


与 aggr queue stats fine stats 日 志 一 起 的 还 有 很 多 项 指标 ， 人 比如 
aggr queue stats deliver get 和 aggr queue stats queue msg counts, HF 
A WATER, KEPER, ANRIA ULEL fT EUECFROSTEUI BIET E TR ER «— STRIS CAS RT fie 
略 有 差异 ， 一 般 情况 下 对 此 无 须 过 多 探究 。 


如 果 使 用 rabbitmqctl stop app 命令 关闭 的 RabbitMQ 应 用 服务 ， 那 么 在 使 用 
rabbitmqctl start app 命令 开启 RabbitMQ 应 用 服务 时 的 启动 日 志和 abbitmq-serve 
的 启动 日 志 相同 。 
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2. 关闭 RabbitMQ 服务 


如 果 使 用 rabbitmqctl stop 命令 ， 会 将 Erlang 虚拟 机 一 同 关闭 ， 而 rabbitmqctl 
stop app 只 关闭 RabbitMQ 应 用 服务 ， 在 关闭 的 时 候 要 多 加 注意 它们 的 区 别 。 下 面 先 看 一 下 
rabbitmqctl stop app 所 对 应 的 服务 日 志 : 


-INFO REPORT==== 3-0ct-2017::10:54:01 === 
Stopping RabbitMQ 


-INFO REPORT---- 3- Oct -2017::10:54:01 === 
stopped TCP Listener on [::]:5672 
-INFO REPORT---- 3- Oct -2017::10:54:01 --- 


Stopped RabbitMQ application 


tn R4 rabbitmqctl stop 来 进行 关闭 操作 , 则 会 多 出 下 面 的 日 志 信息 , 即 关 闭 Erlang 
虚拟 机 。 


-INFO REPORT==== 3- Oct -2017::10:54:01 --- 
Halting Erlang VM 


3. 建立 集群 


建立 集群 也 是 一 种 常用 的 操作 。 这 里 举例 将 节点 rabbit@node2 与 rabbit@nodel 组 成 一 个 集 
群 ， 有 关 如 何 建立 RabbitMQ 集群 的 细节 可 以 参考 7.1 节 。 


首先 在 节点 rabbit@node2 中 执行 rabbitmq-server -detached 开启 Erlang 虚拟 机 和 
RabbitMQ 应 用 服务 ， 之 后 再 执行 rabbitmqctl stop app 来 关闭 RabbitMQ 应 用 服务 ， 具 
体 的 日 志 可 以 参考 前 面 的 内 容 。 之 后 需要 重 置 节点 rabbit@node2 中 的 数据 rabbitmqctl 
reset， 相 应 地 在 节点 rabbit@node2 上 输出 的 日 志 如 下 : 


-INFO REPORT==== 3- Oct -2017::11:25:01 === 
Resetting Rabbit 


在 rabbit(node2 节点 上 执行 rabbitmqctl join clcuster rabbit6nodel , 将 其 加 
入 rabbit@nodel 中 以 组 成 一 个 集群 ， 相 应 地 在 rabbit@node2 节点 中 会 打印 日 志 : 


-INFO REPORT==== 3- Oct -2017::11:30:46 === 
Clustering with [rabbit@nodel] as disc node 


与 此 同时 在 rabbit@nodel 中 会 有 以 下 日 志 : 
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-INFO. REPORT2--- 3- Oct -2017::11:30:56 === 
node rabbit68node2 up 


如 果 此 时 在 rabbit@node2 节点 上 执行 rabbitmqctl stop app 的 动作 ， 那 么 在 
rabbit@nodel 节点 中 会 有 如 下 信息 ; 


-INFO REPORT---- 3- Oct -2017::11:54:01 === 
rabbit on node rabbitünode2 down 


-INFO REPORT---- 3- Oct -2017::11:54:01 --- 
Keep rabbit8node2 listeners: the node is already back 


通过 上 面 的 日 志 可 以 看 出 某 个 RabbitMQ 节点 在 某 个 时 段 的 关闭 /启动 的 动作 。 


4. 其 他 

再 比如 客户 端 与 RabbitMQ 建立 连接 : 

-INFO REPORT---- 14-0ct-2017::16:24:55 --- 

accepting AMQP connection «0.5865.0» (192.168.0.9:61601 -> 192.168.0.2:5672) 
当 客 户 端 强制 中 断 连接 时 : 

=WARNING REPORT==== 14-Jul-2017::16:36:57 === 


closing AMQOP connection <0.5909.0> (192.168.0.9:61629 -> 192.168.0.2:5672) 
connection closed abruptly 


可 以 通过 尝试 各 种 的 操作 以 收集 相应 的 服务 日 志 ， 之 后 组 成 一 个 知识 集 ， 这 个 知识 集 不 单 
单 指 一 个 日 志 列 表 ， 需 要 通过 后 期 的 强化 训练 掌握 其 规律 ， 让 这 个 知识 集 了 然 于 心 。 在 真正 过 
到 异常 故障 的 时 候 可 以 通过 查看 服务 日 志 来 迅速 定位 问题 , 之 后 再 采取 相应 的 措施 以 解决 问题 。 

心得 体会 : 

这 里 作者 有 个 心得 仅 供 参考 ， 在 执行 任何 RabbitMQ 操作 之 前 ， 都 会 打开 一 个 新 的 窗口 运 
ÍT tail -f $RABBITMQ_HOME/var/log/rabbitmq/rabbit@$HOSTNAME.log -n 200 


命令 来 实时 查看 相应 操作 所 对 应 的 服务 日 志 是 什么 ， 久 而 久之 即 可 在 脑海 中 建立 一 个 相对 完备 
的 “知识 集 ”。 


有 时候 RabbitMQ 服务 持久 运行 ， 其 对 应 的 日 志 也 越 来 越 多 ， 尤 其 是 在 遇 到 故障 的 时 候 会 打 
印 很 多 信息 。 有 时 候 也 需要 对 日 志 按照 某 种 规律 进行 切 分 ， 以 便于 后 期 的 管理 。RabbitMQ 中 可 
以 通过 rabbitmqctl rotate logs {suffix} 命 令 来 轮换 日 志 ， 比 如 手工 切换 当前 的 日 志 : 
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rabbitmqctl rotate logs .bak 


之 后 可 以 看 到 在 日 志 目 录 下 会 建立 新 的 日 志文 件 ， 并 且 将 老 的 日 志文 件 以 添加 “ - bak" JA 


级 的 方式 进行 区 分 保存 : 
[root@nodel rabbitmq]f£& ls -al 
«rw-r--r-- IL root root 0 Jul 23 00:50 rabbit8énodel.log 
-rw-r--r-- 1 root root 22646 Jul 23 00:50 rabbitGnodel.log.bak 
-fw-lr--r£-- l root root 0 Jul 23 00:50 rabbit8nodel-sasl.log 
efw-r--r-- l root root 0 Jul 23 00:50 rabbitG8nodel-sasl.log.bak 


也 可 以 执行 一 个 定时 任务 ， 比 如 使 用 Linux crontab， 以 当前 日 期 为 后 级， 每 天 执行 一 次 切 
换 日 志 的 任务 ， 这 样 在 后 面 需要 查阅 日 志 的 时 候 可 以 根据 日 期 快速 定位 到 相应 的 日 志文 件 。 


在 RabbitMQ 中 ,查看 服务 日 志 的 方式 不 止 有 人 工 查看 rabbite $HOSTNAME. log 文件 这 
一 种 。 下 面 介绍 如 何 通过 程序 化 的 方式 来 查看 相应 的 日 志 ，RabbitMQ 默认 会 创建 一 些 交 换 器 ， 
其 中 amq.rabbitmq.log 就 是 用 来 收集 RabbitMQ 日 志 的 ， 集 群 中 所 有 的 服务 日 志 都 会 发 往 
这 个 交换 器 中 。 这 个 交换 器 的 类 型 为 topic, 可 以 收集 如 前 面 所 说 的 debug. info. warning 和 error 
这 4 个 级 别 的 日 志 。 


如 图 7-1 所 示 , 我 们 创建 4 个 日 志 队 列 queue.debug queue.info , queue.warning fil queue.error, 
分 别 采 用 debug. info. warning 和 error 这 4 个 路 由 键 来 绑 定 amq .rabbitmq.1o0g。 如 果 要 使 
用 一 个 队列 来 收集 所 有 级 别 的 日 志 ， 可 以 使 用 “#” 这 个 路 由 键 ， 详 细 内 容 可 以 参考 2.1.4 节 。 


Exchange: amq.rabbitmq.log 
b Overview 
~ Bindings 
This exchange 
y 


To Routing key Arguments 


a 
— ]7 
Qqueue,.error 


info 
[e |] 
m 
queue.warning 





图 7-1 创建 日 志 队列 
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如 果 RabbitMQ 集群 中 只 有 一 个 节点 ,那么 这 4 个 日 志 队 列 可 以 收集 到 此 节点 的 所 有 日 志 。 
对 于 集群 中 有 多 个 节点 的 情况 同样 适用 ， 值 得 注意 的 是 : 对 于 每 个 级 别 的 日 志 队 列 来 说 ， 比 如 
queue.info， 它 会 收 到 每 个 节点 的 info 级 别 的 上 日志， 不 过 这 些 日 志 是 交错 的 ， 不 能 区 分 是 哪个 有 具 
相关 示例 代码 可 以 参考 代码 清单 7-1。 


T 







u 











public class ReceiveLog ( 
public static void main(String[] args) ( 
try ( 

// 省 略 创建 connection… 详 细 内 容 可 参考 代码 清单 1-1 

Channel channelDebug = conncection.createChannel(); 

Channel channelInfo = conncection.createChannel(); 

Channel channelWarn = conncection.createChannel(); 

Channel channelError - conncection.createChannel(); 

// 省 略 channel.basicQos(int prefetch count); 

channelDebug.basicConsume ("queue.debug", false, "DEBUG", 
new ConsumerThread (channelDebug)); 

channelInfo.basicConsume ("queue.info", false, "INFO", 
new ConsumerThread (channelInfo)); 

channelWarn.basicConsume ("queue.warning", false, "WARNING", 
new ConsumerThread (channelWarn)); 

channelError.basicConsume ("queue.error", false, "ERROR", 
new ConsumerThread(channelError)); 

) catch (IOException e) ( 
e.printStackTrace(); 
) catch (TimeoutException e) ( 
e.printStackTrace(); 


) 
public static class ConsumerThread extends DefaultConsumer { 
public ConsumerThread(Channel channel) ( 
super (channel); 
) 
GOverride 
public void handleDelivery(String consumerTag, Envelope envelope, 
AMQP.BasicProperties properties, 
byte[] body) throws IOException ( 
String log = new String (body); 
System.out.println("-2"4consumerTag*" REPORT----An"-109g); 
// 对 日 志 进行 相应 的 处 理 
getChannel().basicAck(envelope.getDeliveryTag(),false); 
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通过 程序 化 的 方式 查看 服务 日 志 ， 可 以 设置 相应 的 逻辑 规则 ， 将 有 用 的 日 志 信息 过 滤 并 保存 
起 来 以 便 后 续 的 服务 应 用 。 也 可 以 对 服务 日 志 添加 监控 ， 比 如 对 其 日 志 内 容 进行 关键 字 检索 ， 在 第 
10 章 中 我 们 会 讨论 网 络 分 区 的 概念 ， 可 以 通过 检索 日 志 的 running partitioned network 
关键 字 来 及 时 地 探测 到 网 络 分 区 的 发 生 ， 之 后 可 以 迅速 采取 措施 以 保证 集群 服务 的 鲁 棒 性 。 当 然 对 
于 日 志 的 监控 处 理 也 可 以 采用 第 3 方 工具 实现 , 如 Logstash 等 , 有 兴趣 的 读者 可 以 进行 拓展 学 习 。 


7.3” 单 节点 故障 恢复 


在 RabbitMQ 使 用 过 程 中 ， 或 多 或 少 都 会 遇 到 一 些 故障 。 对 于 集群 层面 来 说 ， 更 多 的 是 单 
点 故障 。 所 谓 的 单 点 故障 是 指 集群 中 单个 节点 发 生 了 故障 ， 有 可 能 会 引起 集群 服务 不 可 用 、 数 
据 丢 失 等 异常 。 配 置 数 据 节点 见 余 (镜像 队列 ) 可 以 有 效 地 防止 由 于 单 点 故障 而 降低 整个 集群 
的 可 用 性 、 可 靠 性 ， 具 体 细节 可 以 参考 9.4 节 。 本 节 主 要 讨论 的 是 单 节点 故障 有 哪些 ， 以 及 怎 
么 恢复 或 者 处 理 相应 类 型 的 单 节 点 故障 。 


单 节点 故障 包括 : 机 器 硬件 故障 、 机 器 掉 电 、 网 络 异 常 、 服 务 进程 异常 。 


单 节点 机 器 硬件 故障 包括 机 器 硬盘 、 内 存 、 主 板 等 故障 造成 的 死机 ， 无 法 从 软件 角度 来 恢 
复 。 此 时 需要 在 集群 中 的 其 他 节点 中 执行 rabbitmqctl forget cluster node 
(nodename } 命令 来 将 故障 节点 剔除 ， 其 中 nodename 表示 故障 机 器 节点 名 称 。 如 果 之 前 有 客 
户 端 连接 到 此 故障 节点 上 ,在 故障 发 生 时 会 有 异常 报 出 ， 此 时 需要 将 故障 节点 的 IP 地 址 从 连接 
列表 里 删除 ， 并 让 客户 端 重新 与 集群 中 的 节点 建立 连接 ， 以 恢复 整个 应 用 。 如 果 此 故障 机 器 修 
复 或 者 原本 有 备用 机 器 , 那么 也 可 以 选择 性 的 添加 到 集群 中 , 添加 节点 的 操作 可 以 参考 7.1 节 。 


当 遇 到 机 器 掉 电 故障 , 需要 等 待 电源 接 通 之 后 重启 机 器 。 此 时 这 个 机 器 节点 上 的 RabbitMQ 
处 于 stop 状态 , 但 是 此 时 不 要 盲目 重启 服务 ,否则 可 能 会 引起 网 络 分 区 (详细 参考 第 10 章 的 
内 容 )。 此 时 同样 需要 在 其 他 节点 上 执行 rabbitmqctl forget cluster node 
{nodename} 命 令 将 此 节点 从 集群 中 剔除 ， 然 后 删除 当前 故障 机 器 的 RabbitMQ 中 的 Mnesia 
数据 (相当 于 重 置 )， 然 后 再 重启 RabbitMQ 服务 ， 最 后 再 将 此 节点 作为 一 个 新 的 节点 加 入 到 


? Logstash 是 一 款 强大 的 数据 处 理工 具 ， 它 可 以 实现 数据 传输 、 格 式 处 理 、 格 式 化 输出 ， 还 有 强大 的 插件 功能 ， 常 用 于 日 志 处 理 。 
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当前 集群 中 。 


网 线 松动 或 者 网 卡 损 坏 都 会 引起 网 络 故障 的 发 生 。 对 于 网 线 松动 ， 无 论 是 彻底 断 开 ， 还 是 
“ 藉 断 丝 连 ?， 只 要 它 不 降 速 ，RabbitMQ 集群 就 没有 任何 影响 。 但 是 为 了 保险 起 见 ， 建 议 先 关闭 
故障 机 器 的 RabbitMQ 进程 ， 然 后 对 网 线 进行 更 换 或 者 修复 操作 ， 之 后 再 考虑 是 否 重新 开启 
RabbitMQ 进程 。 而 网 卡 故障 极 易 引起 网 络 分 区 的 发 生 ， 如 果 监 控 到 网 卡 故障 而 网 络 分 区 尚未 发 
生 时 ， 理 应 第 一 时 间 关 闭 此 机 器 节点 上 的 RabbitMQ 进程 ， 在 网 卡 修复 之 前 不 建议 再 次 开启 。 
如 果 已 经 发 生 了 网 络 分 区 ， 可 以 参考 10.5 节 进 行 手动 恢复 网 络 分 区 。 


对 于 服务 进程 异常 ， 如 RabbitMQ 进程 非 预期 终止 ， 需 要 预先 思考 相关 风险 是 否 在 可 控 范 
围 之 内 。 如 果 风 险 不 可 控 ， 可 以 选择 抛弃 这 个 节点 。 一 般 情 况 下 ， 重 新 启动 RabbitMQ 服务 进 
程 即 可 。 


以 上 列举 了 几 种 常见 的 RabbitMQ 单 点 故障 ， 但 是 并 不 代表 只 有 这 些 故 障 ， 读 者 可 以 集 思 
广 益 ， 并 实践 验证 如 何 解 决 相应 的 单 点 故障 。 


14 集群 迁移 


对 于 RabbitMQ 运 维 层面 来 说 ， 扩 容 和 迁移 是 必 不 可 少 的 。 扩 容 比较 简单 ， 一 般 向 集群 中 
加 入 新 的 集群 节点 即 可 ， 不 过 新 的 机 器 节点 中 是 没有 队列 创建 的 ， 只 有 后 面 新 创建 的 队列 才 有 
可 能 进入 这 个 新 的 节点 中 。 或 者 如 果 集群 配置 了 镜像 队列 ， 可 以 通过 一 点 “小 手术 ”将 原先 队 
列 “ 漂 移 ” 到 这 个 新 的 节点 中 ， 具 体 可 以 参考 第 10.5 节 。 

迁移 同样 可 以 解决 扩容 的 问题 , 将 旧 的 集群 中 的 数据 (包括 元 数据 信息 和 消息 ) 迁移 到 新 
的 且 容 量 更 大 的 集群 中 即 可 。RabbitMQ 中 的 集群 迁移 更 多 的 是 用 来 解决 集群 故障 不 可 短 时 间 
内 修复 而 将 所 有 的 数据 、 客 户 端 连接 等 迁移 到 新 的 集群 中 ， 以 确保 服务 的 可 用 性 。 相 比 于 单 
点 故障 而 言 ， 集 群 故障 的 危害 性 就 大 得 多 ， 比 如 IDC 整体 停电 、 网 线 被 挖 断 等 。 这 时 候 就 需 
要 通过 集群 迁移 重新 建立 起 一 个 新 的 集群 。 


RabbitMQ 集群 迁移 包括 元 数据 重建 、 数 据 迁 移 ， 以 及 与 客户 端 连接 的 切换 。 
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7.4.1 元 数据 重建 


元 数据 重建 是 指 在 新 的 集群 中 创建 原 集群 的 队列 、 交 换 器 、 绑 定 关系 、vhost、 用 户 、 权 限 
和 Parameter 等 数据 信息 。 元 数据 重建 之 后 才 可 将 原 集群 中 的 消息 及 客户 端 连接 迁移 过 来 。 


有 很 多 种 方法 可 以 重建 元 数据 ， 比 如 通过 手工 创建 或 者 使 用 客户 端 创建 。 但 是 在 这 之 前 最 
耗 时 耗 力 的 莫 过 于 对 元 数据 的 整理 ， 如 果 事 先 没 有 统筹 规划 ， 通 过 人 工 的 方式 来 完成 这 项 工作 
是 极其 烦琐 、 低 效 的 ， 且 时 效 性 太 差 ， 不 到 万 不 得 已 不 建议 使 用 。 高 效 的 手段 莫 过 于 通过 Web 
管理 界面 的 方式 重建 ， 在 Web 管理 界面 的 首页 最 下 面 有 如 图 7-2 所 示 的 内 容 ， 这 里 展示 的 是 
3.6.10 版 本 的 界面 ， 之 前 的 很 多 版 本 下 面 的 两 项 是 并 排 排列 的 ， 而 非 竖 着 排列 ， 但 总 体 上 没有 
任何 影响 。 


* Export definitions 


Filename for download: 
mecadaca.json 
wv Import definitions 


Definitions file: 
| 选择 文件 | 未 选择 任何 文件 





图 7-2 元 数据 上 传 与 下 载 


可 以 在 原 集群 上 点 击 “Download broker definitions” 按 钮 下 载 集群 的 元 数据 信息 文件 ， 此 文 
件 是 一 个 JSON 文件 ， 比 如 命名 为 metadata.json， 其 内 部 详细 内 容 可 以 参考 附录 A。 之 后 再 在 
新 集群 上 的 Web 管理 界面 中 点 击 “Upload broker definitions” 按 钮 上 传 metadata.json 文件 ， 如 
果 导 入 成 功 则 会 跳 转 到 如 图 7-3 所 示 的 页 面 , 这 样 就 迅速 在 新 集群 中 创建 了 元 数据 信息 ,注意 ， 
如 果 新 集群 有 数据 与 metadata.json 中 的 数据 相 冲 突 ， 对 于 交换 器 、 队 列 及 绑 定 关 系 这 类 非 可 变 
对 象 而 言 会 报错 ， 而 对 于 其 他 可 变 对 象 如 Parameter、 用 户 等 则 会 被 覆盖 ， 没 有 发 生 冲 突 的 则 不 
受 影 响 。 如 果 过 程 中 发 生 错误 , 则 导入 过 程 终止 , 导致 metadata.json 中 只 有 部 分 数据 加 载 成 功 。 
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RabbitMQ 3.6.10, Erlang 19.1 
Overview Connections Channels Exchanges Queues Admin Virtual host: | All Y 


Import succeeded 


Your definitions were imported successfully. 


HTTP API | Command Line Update | every 5 seconds v 


Last update: 2017-08-25 19:13:30 





7-3 ”导入 成 功 后 跳 转 的 页 面 


上 面 这 种 方式 需要 考虑 三 个 问题 。 第 一 ， 如 果 原 集群 突 发 故障 ， 又 或 者 开启 RabbitMQ 
Management 插件 的 那个 节点 机 器 故障 不 可 修复 ， 就 无 法 获取 原 集群 的 元 数据 metadata.json， 这 
样 元 数据 重建 就 无 从 谈 起 。 这 个 问题 也 很 好 解决 ， 我 们 可 以 采取 一 个 通用 的 备份 任务 ， 在 元 数 
据 有 变更 或 者 达到 某 个 存储 周期 时 将 最 新 的 metadata.json 备份 至 男 一 处 安全 的 地 方 。 这 样 在 过 
到 需要 集群 迁移 时 ， 可 以 获取 到 最 新 的 元 数据 。 


第 二 个 问题 是 ， 如 果 新 旧 集 群 的 RabbitMQ 版 本 不 一 致 时 会 出 现 异 常情 况 ， 比 如 新 建立 了 
一 个 3.6.10 版 本 的 集群 ， 旧 集群 版 本 为 3.5.7， 这 两 个 版 本 的 元 数据 就 不 相同 。3.5.7 版 本 中 的 
user 这 一 项 的 内 容 如 下 ， 与 3.6.10 版 本 的 加 密 算法 是 不 一 样 的 。 可 以 参考 附录 A 中 的 相关 项 以 
进行 对 比 。 

"users": [ 

{ 
"name": "guest", 


"password hash": "1575p97Bd6fYgsjFrCVBsWO9Jhs-", 
"tags": "administrator" 


"name": "root", 
"password hash": "z48XwYsMasTeRE4zzhDuj3ItVx0-", 
"tags": "administrator" 


l; 

再 者 ，3.6.10 版 本 中 的 元 数据 JSON 文件 比 3.5.7 版 本 中 多 了 global parameters 这 一 
项 。 一 般 情 况 下 ，RabbitMQ 是 能 够 做 到 向 下 兼容 的 ， 在 高 版 本 的 RabbitMQ 中 可 以 上 传 低 版 本 
的 元 数据 文件 。 然 而 如 果 在 低 版 本 中 上 传 高 版 本 的 元 数据 文件 就 没有 那么 顺利 了 ， 就 以 3.6.10 
版 本 的 元 数据 加 载 到 3.5.7 版 本 中 就 会 出 现 用 户 登 录 失败 的 情况 为 例 ， 因 为 密码 加 密 方式 变 了 ， 
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这 里 可 以 简单 地 在 Shell 控制 台 输 入 变更 密码 的 方式 来 解决 这 个 问题 : 


rabbitmqctl change password {username} {new password) 


如 果 还 是 不 能 成 功 上 传 元 数据 ， 那 么 就 需要 进一步 采取 措施 了 。 在 此 之 前 ， 我 们 首选 需要 
明确 一 个 概念 ， 就 是 对 于 用 户 、 策 略 、 权 限 这 种 元 数据 来 说 内 容 相对 固定 ， 且 内 容 较 少 ， 手 工 
重建 的 代价 较 小 。 而 且 在 一 个 新 集群 中 要 能 让 Web 管理 界面 运作 起 来 ， 本 身 就 需要 创建 用 户 、 
设置 角色 及 添加 权限 等 。 相 反 ， 集 群 中 元 数据 最 多 且 最 复杂 的 要 数 队 列 、 交 换 器 和 绑 定 这 三 项 
的 内 容 ， 这 三 项 内 容 还 涉及 其 内 容 的 参数 设置 ， 如 果 采 用 人 工 重 建 的 方式 代价 太 大 ， 重 建 元 数 
据 的 意义 其 实 就 在 于 重建 队列 、 交 换 器 及 绑 定 这 三 项 的 相关 信息 。 


这 里 有 个 小 窍门 ， 可 以 将 3.6.10 的 元 数据 从 queues 这 一 项 前 面 的 内 容 ， 包 括 rabbit 
version.users.vhosts.permissions.parameters.global Parameters Il policies 
这 几 项 内 容 复制 后 替换 3.5.7 版 本 中 的 queues 这 一 项 前 面 的 所 有 内 容 ， 然 后 再 保存 。 之 后 将 修改 
并 保存 过 后 的 3.5.7 版 本 的 元 数据 JSON 文件 上 传 到 新 集群 3.6.10 版 本 的 Web 管理 界面 中 ， 至 此 就 
完成 了 集群 的 元 数据 重建 〈 阅 读 这 一 段落 时 可 以 对 照 着 附录 A 的 内 容 来 加 深 理解 )。 


第 三 个 问题 就 是 如 果 采 用 上 面 的 方法 将 元 数据 在 新 集群 上 重建 ， 则 所 有 的 队列 都 只 会 落 到 同 
一 个 集群 节点 上 ， 而 其 他 节点 处 于 空置 状态 ， 这 样 所 有 的 压力 将 会 集中 到 这 单 台 节点 之 上 。 举 个 
例子 , 新 集群 由 nodel、node2、node3 节点 组 成 , 其 节点 的 了 P 地 址 分 别 为 192.168.0.2、192.168.0.3 
和 192.168.0.4。 当 访问 http://192.168.0.2:15672 页 面 时 ,并 上 传 了 原 集群 的 元 数据 文件 metadata.json, 
那么 原 集群 的 所 有 队列 将 只 会 在 nodel 节点 上 重新 建立 ， 如 图 7-4 中 方 框 标记 所 示 。 


Overview Messages 
Name Node Features State Ready Unacked Total 








ida. laani 0 Wn: ll al 9 
|* ide 0 0: 0 
E MEAE TET 


7-4 重建 示例 


处 理 这 个 问题 ， 有 两 种 方式 ， 都 是 通过 程序 〈 或 者 脚本 ) 的 方式 在 新 集群 上 建立 元 数据 ， 
而 非 简单 地 在 页 面 上 上 传 元 数据 文件 而 已 。 第 一 种 方式 是 通过 HTTPAPI 接 口 创 建 相应 的 数据 。 
下 面 通过 一 个 相对 完整 的 Java 程序 来 详细 介绍 第 一 种 方式 ， 这 里 主要 是 创建 队列 、 交 换 器 和 绑 
定 关 系 ， 而 其 他 内 容 则 忽略 。 
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首先 需要 创建 队列 、 交 换 器 和 绑 定 关系 对 应 的 JavaBean, 分 别 为 Queue.java、Exchange.java 
和 Binding.java。 详 细 内 容 参 考 下 方 代码 清单 7-2. 








public class Queue {// 与 附录 A 中 相关 内 容 一 一 对 应 
private String name; 
private String vhost; 
private Boolean durable; 
private Boolean auto delete; 
private Map<String, Object> arguments; 


// 省 略 Getter 和 Setter 方法 … 


public class Exchange { 
private String name; 
private String vhost; 
private String type; 
private Boolean durable; 
private Boolean auto delete; 
private Boolean internal; 
private Map«String, Object» arguments; 
// 省 略 Getter 和 Setter 方法 … 


public class Binding { 
private String source; 
private String vhost; 
private String destination; 
private String destination type; 
private String routing key; 
private Map«String, Object» arguments; 
// 省 略 Getter 和 Setter 方法 … 
} 


进一步 ， 需 要 解析 原 集群 的 metadatajson 文件 。 下 面 程序 采用 Gson? 来 解析 此 文件 中 的 
queues, exchanges fll bindings 这 三 项 内 容 ， 并 分 别 保存 到 相应 的 列表 之 中 。 详 细 请 参考 
代码 清单 7-3。 





private static List<Queue> queueList = new ArrayList«Queue»(); 
private static List«Exchange» exchangeList = new ArrayList«Exchange»(); 


3 Gson 是 Google 开发 的 Java API， 用 于 转换 Java 对 象 和 JSON 对 象 。 
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private static List«Binding» bindingList = new ArrayList«Binding»(); 


private static void parseJson (String filename) { 
JsonParser parser - new JsonParser(); 
try ( 
JsonObject json = (JsonObject) parser.parse (new 
FileReader(filename)); 
JsonArray jsonQueueArray - json.get("queues").getAsJsonArray(); 
for (int i = 0; i < jsonQueueArray.size(); i++) ( 
JsonObject subObject = jsonQueueArray.get(i).getAsJsonObject(); 
Queue queue - parseQueue (subObject); 
queueList.add (queue); 
} 
JsonArray jsonExchangeArray = 
json.get ("exchanges") .getAsJsonArray(); 
for (int i-0;i«jsonExchangeArray.size();i**) ( 
JsonObject subObject - 
jsonExchangeArray.get (i).getAsJsonObject(); 
Exchange exchange = parseExchange (subObject); 
exchangeList.add (exchange); 
} 
JsonArray jsonBindingArray = json.get("bindings").getAsJsonArray(); 
for (int i-0;i«€jsonBindingArray.size();i*-*) ( 
JsonObject subObject = jsonBindingArray.get(i).getAsJsonObject(); 
Binding binding = parseBinding(subObject); 
bindingList.add (binding); 
} 
} catch (FileNotFoundException e) { 
e.printStackTrace(); 


} 


// 解 析 队 列 信息 

private static Queue parseQueue(JsonObject subObject) { 
Queue queue = new Queue(); 
queue.setName (subObject.get ("name").getAsString()); 
queue.setVhost (subObject.get ("vhost").getAsString()); 
queue.setDurable (subObject.get ("durable").getAsBoolean()); 
queue.setAuto delete(subObject.get("auto delete").getAsBoolean()); 
JsonObject argsObject - subObject.get("arguments").getAsJsonObject(); 
MapcString, Object» map = parseArguments (argsObject); 
queue.setArguments (map); 
return queue; 


) 


// 解 析 交 换 器 信息 


private static Exchange parseExchange (JsonObject subObject) { 
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// 省 略 ， 有 具体 参考 parseQueue 方法 进行 推演 


} 
// 解 析 绑 定 信息 
private static Binding parseBinding(JsonObject subObject) ( 
// 省 略 ， 上 具体 参考 parseQueue 方法 进行 推演 
} 


// 解 析 参 数 arguments 这 一 项 内 容 
private static Map<String,Object> parseArguments (JsonObject argsObject)( 
Map«String, Object» map = new HashMapcXString, Object»(); 
Set«Map.Entry«String, JsonElement»» entrySet = argsObject.entrySet(); 
for (Map.Entry«String, JsonElement» mapEntry : entrySet) ( 
map.put (mapEntry.getKey(), mapEntry.getValue()); 
) 


return map; 


) 


在 解析 完 队 列 、 交 换 器 及 绑 定 关系 之 后 ， 只 需要 遍历 queueList. exchangeList 和 
bindingList， 然 后 调用 HTTP API 创建 相应 的 数据 即 可 。 注 意 在 下 面 代码 清单 7-4 的 
createQueues 方法 中 ， 我 们 随机 挑选 一 个 节点 并 明确 指明 了 “node” 节 点 这 一 参数 来 创建 队 
列 ， 如 此 便 可 解决 集群 内 部 队列 分 布 不 均匀 的 问题 。 当 然 首 先 需要 确定 新 集群 中 节点 名 称 的 列 
表 ， 如 以 下 nodeList 所 示 。 


jr 





private static final String ip = "192.168.0.2"; 

private static final String username = "root"; 

private static final String password = "root123"; 

private static final List<String> nodeList = new ArrayList<String>(){{ 
add ("rabbit@node1"); 
add ("rabbit@node2"); 
add ("rabbit@node3"); 

) 


// 创 建 队列 
private static Boolean createQueues() { 
try ( 
for (int i-0;i«queueList.size();i-**) ( 
Queue queue - queueList.get(i); 
// 注 意 将 特殊 字符 转 义 ， 比 如 默认 的 vhost="/"， 将 其 转 成 $2F 
String url = String.format ("http://%s:15672/api/queues/%s/%s", ip, 
encode (queue.getVhost(),"UTF-8"), 
encode (queue.getName () , "UTF-8")); 
Map<String, Object» map = new HashMapcString, Object»^(); 
map.put("auto delete", queue.getAuto delete()); 
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map.put("durable", queue.getDurable()); 
map.put("arguments", queue.getArguments()); 

// 随 机 挑选 一 个 节点 ， 并 在 此 节点 上 创建 相应 的 队列 

//int index = (int) (Math.random() * nodeList.size()); 
//map.put("node", nodeList.get (index)); 
Collections.shuffle (nodeLlist); 

map.put("node", nodeList.get(0)); 

String data = new Gson().toJson (map); 


System.out.println(url); 
System.out.println(data); 
httpPut (url,data,username,password); 
} 
} catch (UnsupportedEncodingException e) { 
e.printStackTrace(); 
return false; 
) catch (IOException e) ( 
e.printStackTrace(); 
return false; 
} 
return true; 


} 


// 创 建交 换 器 
private static Boolean createExchanges () { 
// 省 略 ， 具 体 参 考 createQueues 方法 进行 推演， 关键 信息 如 url 
String url = String.format ("http://$s:15672/api/exchanges/$s/$s",ip, 
encode (exchange.getVhost(),"UTF-8"), 
encode (exchange.getName (),"UTF-8")); 


} 


// 创 建 绑 定 关 系 
private static Boolean createBindings()í 
// 省 略 ， 具 体 参 考 createQueues 方法 进行 推演 ， 关 键 信息 如 url 
String url = null; 
// 绑 定 有 两 种 :交换 器 与 队列 ， 交 换 器 与 交换 器 
if (binding.getDestination type().equals("queue")) { 
url = String.format ("http://$s:15672/api/bindings/$s/e/$s/q/S$s", ip, 
encode (binding.getVhost(),"UTF-8"), 
encode (binding.getSource(),"UTF-8"), 
encode (binding.getDestination(),"UTF-8")); 


url = String.format ("http://$s:15672/api/bindings/$s/e/$s/e/$s", ip, 
encode (binding.getVhost(),"UTF-8"), 
encode (binding.getSource(),"UTF-8"), 
encode (binding.getDestination(),"UTF-8")); 
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} 
) 
// http Post 
public static int httpPut(String url, String data, String username, String 
password) throws IOException { 
HttpClient client = new HttpClient(); 
client.getState().setCredentials (AuthScope.ANY, 
new UsernamePasswordCredentials (username, password)); 
PutMethod putMethod = new PutMethod (url); 
putMethod.setRequestHeader ("Content-Type","application/json; 
charset-UTF-8"); 
putMethod.setRequestEntity (new 
StringRequestEntity (data, "application/json","UTF-8")); 
int statusCode = client.executeMethod (putMethod) ; 
//System.out.println(statusCode); 
return statusCode; 
} 
public static int httpPost(String url, String data, String username, String 
password) throws IOException ( 
// 省 略 ， 具 体 参考 nttpPut 方法 进行 推演 
} 


通过 使 用 Gson 解析 metadata.json 文件 ， 进 而 使 用 HttpClient 调用 相应 的 HTTP API 在 随机 


的 节点 上 创建 相应 的 队列 进程 ， 从 而 达到 了 集群 节点 负载 均衡 的 目的 。 建 议 读者 试 着 将 上 面 的 
Java 程序 转换 成 相应 的 脚本 程序 ， 可 以 更 加 方便 地 执行 与 修改 。 


上 面 介绍 了 通过 调用 HTTP. API 的 接口 来 指定 相应 的 节点 进行 创建 队列 。 这 里 还 有 一 种 方 
式 是 随机 连接 集群 中 不 同 的 节点 的 IP 地 址 ， 然 后 再 创建 队列 。 与 前 一 种 方式 需要 节点 名 称 的 列 
表 不 同 ， 这 里 需要 的 是 节点 P 地 址 列表 ， 如 代码 清单 7-5 所 示 。 





private static List<String> ipList = new ArrayList<String>(){{ 
add("192.168.0.2"); 
add(^192.168.0.3"); 
add ("192.168.0.4"); 


b}; 


客户 端 通过 连接 不 同 的 P 地 址 来 创建 不 同 的 connection # channel, 然后 将 channel 
存 入 一 个 缓冲 池 ， 如 图 7-5 所 示 的 channelList。 之 后 随机 从 channelList 中 获取 一 个 
channel， 再 根据 queueList 中 的 信息 创建 相应 的 队列 。 


^ 这 里 采用 的 HttpClient 是 指 org.apache.commons.httpclient HttpClient。 
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ipList: 
ip1:192.168.0.2 
L2----*7777 dp2:192.168.0.3 


Client <- 一 一 ip3:192.168.0.4 





n 


queue information 


7-5 随机 创建 队列 


每 一 个 channel 对 应 一 个 connection, 而 每 一 个 connection 又 对 应 一 个 IP, 这 样 串 
起 来 就 能 保证 channelList 中 不 会 遗留 任何 节点 ， 最 终 实 现 与 第 一 种 方式 相同 的 功能 。 对 应 
的 队列 创建 代码 如 代码 清单 7-6 所 示 。 





private static void createQueuesNew()í 
List«Channel» channelList = new ArrayList«Channel»(); 
List«Connection» connectionList = new ArrayList«Connection»(); 
try ( 
for (int i = 0; i < ipList.size(): i++) ( 
String ip = ipList.get(i); 
ConnectionFactory connectionFactory - new ConnectionFactory(); 
connectionFactory.setUsername (username); 
connectionFactory.setPassword (password); 
connectionFactory.setHost (ip); 
connectionFactory.setPort (5672); 
Connection connection = connectionFactory.newConnection(); 
Channel channel = connection.createChannel(); 
channelList.add (channel); 
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connectionList.add(connection); 
) 
createQueueByChannel (channelList); 
) catch (IOException e) ( 
e.printStackTrace(); 
) catch (TimeoutException e) { 
e.printStackTrace(); 
) finally ( 
for (Connection connection : connectionList) ( 
try 1 
connection.close(); 
) catch (IOException e) ( 
e.printStackTrace(); 


) 


} 
} 
private static void createQueueByChannel (List<Channel> channelList) { 
for (int i=0;i<queueList.size();i++) { 
Queue queue = queueList.get (i); 
// 随 机 获取 相应 的 channel 
Collections.shuffle(channelList); 
Channel channel = channelList.get (0); 
try ( 
Map<String, Object» mapArgs = queue.getArguments(); 
//do something with mapArgs. 
channel.queueDeclare (queue.getName(), queue.getDurable(), 
false, queue.getAuto delete(), mapArgs); 
) catch (IOException e) { 
e.printStackTrace(); 
) 


7.4.2 ”数据 迁移 和 客户 端 连 接 的 切换 


上 一 节 陈述 如 何 重建 RabbitMQ 元 数据 ， 此 为 集群 迁移 前 必要 的 准备 工作 ， 本 节 阐 述 在 迁 
移 过 程 中 的 主要 工作 。 


首先 需要 将 生产 者 的 客户 端 与 原 RabbitMQ 集群 的 连接 断 开 ， 然 后 再 与 新 的 集群 建立 新 的 
连接 ， 这 样 就 可 以 将 新 的 消息 流转 入 到 新 的 集群 中 。 
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之 后 就 需要 考虑 消费 者 客户 端的 事情 ， 一 种 是 等 待 原 集群 中 的 消息 全 部 消费 完 之 后 再 将 连 
接 断 开 ， 然 后 与 新 集群 建立 连接 进行 消费 作业 。 可 以 通过 Web 页 面 查 看 消息 是 否 消 费 完 成 ， 可 
以 参考 图 7-4。 也 可 以 通过 rabbitmqctl list queues name messages messages ready 
messages unacknowledged 命令 来 查看 是 否 有 未 被 消费 的 消息 。 


当 原 集群 服务 不 可 用 或 者 出 现 故 障 造成 服务 质量 下 降 而 需要 迅速 将 消息 流 切 换 到 新 的 集群 
中 时 ， 此 时 就 不 能 等 待 消费 完 原 集群 中 的 消息 ， 这 里 需要 及 时 将 消费 者 客户 端的 连接 切换 到 新 
的 集群 中 ， 那 么 在 原 集群 中 就 会 残留 部 分 未 被 消费 的 消息 ， 此 时 需要 做 进一步 的 处 理 。 如 果 原 
集群 损坏 ， 可 以 等 待 修复 之 后 将 数据 迁移 到 新 集群 中 ， 否 则 会 丢失 数据 。 


如 图 7-6 所 示 ， 数 据 迁 移 的 主要 原理 是 先 从 原 集群 中 将 数据 消费 出 来 ， 然 后 存 入 一 个 缓存 
区 中 ， 另 一 个 线程 读 取 缓 存 区 中 的 消息 再 发 布 到 新 的 集群 中 ， 如 此 便 完成 了 数据 迁移 的 动作 。 
作者 将 此 命名 为 “RabbitMQ ForwardMaker”， 读 者 可 以 自行 编写 一 个 小 工具 来 实现 这 个 功能 。 
RabbitMQ 本 身 提供 的 Federation 和 Shovel 插件 都 可 以 实现 RabbitMQ ForwardMaker 的 功能 , 确 
切 地 说 Shovel 插件 更 贴近 RabbitMQ ForwardMaker， 详 细 可 以 参考 第 8 章 ， 不 过 自 定义 的 
RabbitMQ ForwardMaker 工具 可 以 让 迁移 系统 更 加 高 效 、 灵 活 。 


-RabbitMQ ForwardMaker- 


Ed i | 
HeH 


图 7-6 数据 迁移 
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7.4.3 自动 化 迁移 





要 实现 集群 自动 化 迁移 ， 需 要 在 使 用 相关 资源 时 就 做 好 一 些 准备 工作 ， 方 便 在 自动 化 迁移 
过 程 中 进行 无 缝 切换。 与 生产 者 和 消费 者 客户 端 相关 的 是 交换 器 、 队 列 及 集群 的 信息 ， 如 果 这 
3 种 类 型 的 资源 发 生 改变 时 需要 让 客户 端 迅速 感知 ， 以 便 进 行 相应 的 处 理 ， 则 可 以 通过 将 相应 
的 资源 加 载 到 ZooKeeper 的 相应 节点 中 ， 然 后 在 客户 端 为 对 应 的 资源 节点 加 入 watcher 来 感知 
变化 ， 当 然 这 个 功能 使 用 eted 或 者 集成 到 公司 层面 的 资源 配置 中 心中 会 更 加 标准 、 高 效 。 


如 图 7-7 所 示 , 将 整个 RabbitMQ 集群 资源 的 使 用 分 为 三 个 部 分 : 客户 端 、 集 群 、ZooKeeper 
配置 管理 。 





cluster=cluster1 1 
i! exchangeType-direct | 
i vhost=vhost1 i 


i tt a 
exchange2 A 
-— L1 BEÜFADAR SU eer arn E 
queues E clusterzcluster1 
queuel....... a bindingszexchangei ' 
queue2 5 vhostzvhosti ! 
we 1| usernamezroot H 
clusters jj password=root123 
clusteri----. ^ GEIL Adb EIUS 
[ Mtt Am m mmm 
cluster2 Y! ipList-192.168.0.2,1921 
T u 68.0.3,192.168.0.4 


Arm tren omm mmm mmm mmn 


| ————á( 


7-7 自动 化 迁移 


在 集群 中 创建 元 数据 资源 时 都 需要 在 ZooKeeper 中 生成 相应 的 配置 ， 比 如 在 clusterl 集群 
中 创建 交换 器 exchangel 之 后 ， 需 要 在 /rmqNode/exchanges 路 径 下 创建 实 节点 exchangel, 
并 赋予 节点 的 数据 内 容 为 : 


5 eted 是 一 个 分 布 式 一 致 性 k-v 存储 系统 ， 可 用 于 服务 注册 发 现 与 共享 配置 。 官 网 地 址 为 https://coreos.com/etcd/. 
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cluster-clusterl :# 表 示 此 交换 器 所 在 的 集群 名 称 
exchangeType-direct # 表 示 此 交换 器 的 类 型 
vhost-vhostl # 表 示 此 交换 器 所 在 的 vhost 
username-root }# 表 示 用 户 名 
password-rootl23 # 表 示 密 码 


同样 ， 在 clusterl 集群 中 创建 队列 queuel 之 后 ， 需 要 在 /rmqNode/queues 路 径 下 创建 实 
节点 queue1， 并 赋予 节点 的 数据 内 容 为 : 


cluster-clusterl 

bindings-exchangel # 表 示 此 队列 所 绑 定 的 交换 器 
# 如 果 有 需要 ， 也 可 以 添加 一 些 其 他 信息 ， 比 如 路 由 键 等 
vhost=vhost1 

usern&àme-root 

password-root123 


对 应 集群 的 数据 在 /rmqNode/clusters 路 径 下 ， 比 如 clusterl 集群 ， 其 对 应 节点 的 数据 
内 容 包含 IP 地 址 列表 信息 : 
ipList-192.168.0.2,192.168.0.3,192.168.0.4 # 集 群 中 各 个 节点 的 IP 地 址 信息 


客户 端 程序 如 果 与 其 上 的 交换 器 或 者 队列 进行 交互 ， 那 么 需要 在 相应 的 ZooKeeper 节点 中 
添加 watcher， 以 便 在 数据 发 生变 更 时 进行 相应 的 变更 ， 从 而 达到 自动 化 迁移 的 目的 。 


生产 者 客户 端 在 发 送 消息 之 前 需要 先 连接 ZooKeeper， 然 后 根据 指定 的 交换 器 名 称 如 
exchangel 到 相应 的 路 径 /rmqNode/exchanges 中 寻找 exchangel 的 节点 , 之 后 再 读 取 节 点 中 
的 数据 ， 并 同时 对 此 节点 添加 watcher。 在 节点 的 数据 第 一 条 “cluster=cluster1” 中 找到 交换 器 
所 在 的 集群 名 称 ， 然 后 再 从 路 径 /rmqNode/clusters 中 寻找 clusterl 节点 ， 然 后 读 取 其 对 应 
的 IP 地 址 列表 信息 。 这 样 整个 发 送 端 所 需要 的 连接 串 数据 (IP 地 址 列表 、vhost、username、 
password 等 ) 都 已 获取 ， 接 下 就 可 以 与 RabbitMQ 集群 clusterl 建立 连接 然后 发 送 数据 了 。 


对 于 消费 者 客户 端 而 言 ， 同 样 需要 连接 ZooKeeper， 之 后 根据 指定 的 队列 名 称 〈queuel ) 
到 相应 的 路 径 /rmqNode/queues 中 寻找 queuel 节点 ， 继 而 找到 相应 的 连接 串 ， 然 后 与 
RabbitMQ 集群 clusterl 建立 连接 进行 消费 ,当然 对 /rmqNode/queues/queuel 节点 的 watcher 
必 不 可 少 。 


当 cluster! 集群 需要 迁移 到 cluster2 集群 时 , 首先 需要 将 clusterl 集群 中 的 元 数据 在 cluster2 
集群 中 重建 。 之 后 通过 修改 zk 的 channel 和 queue 的 元 数据 信息 ,比如 原 clusterl 集群 中 有 交换 
器 exchangel、exchange2 和 队列 queuel、queue2, 现 在 通过 脚本 或 者 程序 将 其 中 的 “cluster=cluster1” 
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数据 修改 为 “cluster=cluster2”。 客 户 端 会 立刻 感知 节点 的 变化 ， 然 后 迅速 关闭 当前 连接 之 后 再 
与 新 集群 cluster2 建立 新 的 连接 后 生产 和 消费 消息 ， 在 此 切换 客户 端 连接 的 过 程 中 是 可 以 保证 
数据 零 丢 失 的 。 迁 移 之 后 ， 生 产 者 和 消费 者 都 会 与 cluster2 集群 进行 互通 ， 此 时 原 cluster! 集群 
中 可 能 还 有 未 被 消费 完 的 数据 ， 此 时 需要 使 用 7.4.2 节 所 述 的 RabbitMQ ForwardMaker 工具 将 
cluster! 集群 中 未 被 消费 完 的 数据 同步 到 cluster2 集群 中 。 


如 果 没 有 准备 RabbitMQ ForwardMaker 工具 ， 也 不 想 使 用 Federation 或 者 Shovel 插件 ， 那 
么 在 变更 完 交 换 器 相关 的 ZooKeeper 中 的 节点 数据 之 后 ， 需 要 等 待 原 集群 中 的 所 有 队列 都 消费 
完全 之 后 ， 再 将 队列 相关 的 ZooKeeper 中 的 节点 数据 变更 ， 进 而 使 得 消费 者 的 连接 能 够 顺利 迁 
移 到 新 的 集群 之 上 。 可 以 通过 下 面 的 命令 来 查看 是 否 有 队列 中 的 消息 未 被 消费 完 ， 


rabbitmqctl list queues -p / -q | awk '{if($2>0) print $0}' 


上 面 的 自动 化 迁移 立足 于 将 现 有 集群 迁移 到 空闲 的 备份 集群 ， 如 果 由 于 原 集群 硬件 升级 等 
原因 迁移 也 无 可 厚 非 。 很 多 情况 下 ， 自 动 化 迁移 作为 容 灾 手段 中 的 一 种 ， 如 果 有 很 多 个 正在 运 
行 的 RabbitMQ 集群 ， 为 每 个 集群 都 配备 一 个 空闲 的 备份 集群 无 疑 是 一 种 资源 的 浪费 。 当 然 可 
以 采取 几 个 集群 共用 一 个 备份 集群 来 减少 这 种 浪费 ， 那 么 有 没有 更 优 的 解决 方案 呢 ? 

就 以 4 个 RabbitMQ 集群 为 例 ， 其 被 分 配 4 个 独立 的 业务 使 用 。 如 图 7-8 所 示 ，clusterl 集 
群 中 的 元 数据 备份 到 cluster2 集群 中 ， 而 cluster2 集群 中 的 元 数据 备份 到 cluster3 集群 中 ， 如 此 
可 以 两 两 互 备 。 比 如 在 clusterl 集群 中 创建 了 一 个 交换 器 exchange1， 此 时 需要 在 cluster2 集群 
中 同样 创建 一 个 交换 器 exchangel。 在 正常 情况 下 ， 使 用 的 是 clusterl 集群 中 的 exchangel, mi 
exchangel 在 cluster2 集群 中 只 是 一 份 记 录 ， 并 不 消耗 cluster2 集群 的 任何 性 能 。 而 当 需 要 将 
clusterl 迁移 时 , 只 需要 将 交换 器 及 队列 相对 应 的 ZooKeeper 节点 数据 项 变更 即 可 完成 迁移 的 工 
作 。 如 此 既 不 用 耗费 额外 的 硬件 资源 ， 又 不 用 再 迁移 的 时 候 重 新 建立 元 数据 信息 。 


为 了 更 加 稳妥 起 见 ， 也 可 以 准备 一 个 空闲 的 备份 集群 以 备 后 用 。 当 cluster! 集群 需要 迁移 
到 cluster2 集群 中 时 ，cluster2 集群 已 经 发 生 故障 被 关闭 或 者 被 迁移 到 cluster3 集群 中 了 ， 那 么 
这 个 空闲 的 备份 集群 可 以 当 作 “Plan B” 来 增强 整体 服务 的 可 靠 性 。 如 果 既 想 不 浪费 多 余 的 硬 
件 资源 又 想 具 备 更 加 稳妥 的 措施 ， 可 以 参考 图 7-9， 将 clusterl 中 的 元 数据 备份 到 cluster2 和 
cluster3 中 ， 这 样 “ 以 1 备 2” 的 方式 即 可 解决 这 个 难题 。 
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图 7-9 “以 1 备 2” 的 备份 方式 


对 于 上 面 介绍 的 多 集群 间 互 备 的 解决 方案 需要 配套 一 个 完备 的 实施 系统 ， 比 如 具备 资源 管 
理 、 执 行 下 发 、 数 据 校 对 等 功能 ， 并 且 对 于 ZooKeeper 节点 中 的 数据 项 设计 也 需要 细 细 持 酌 ， 
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最 好 能 够 根据 实际 使 用 情况 将 这 些 整 合 到 一 个 大 的 平台 化 系统 之 中 。 


7.5 ”集群 监控 


任何 应 用 功能 再 强大 、 性 能 再 优越 ， 如 果 没 有 与 之 匹配 的 监控 那么 一 切 都 是 虚无 绿 纳 的 。 
监控 不 仅 可 以 提供 运行 时 的 数据 为 应 用 提供 依据 参考 ， 还 可 以 迅速 定位 问题 、 提 供 预 防 及 告警 
等 功能 ， 很 大 程度 上 增强 了 整体 服务 的 鲁 棒 性 。RabbitMQ 扩展 的 RabbitMQ Management 插件 
就 能 提供 一 定 的 监控 功能 , 参考 图 5-1，Web 管理 界面 提供 了 很 多 的 统计 值 信息 : 如 发 送 速度 、 
确认 速度 、 消费 速度 、 消息 总 数 、 磁盘 读 写 速度 、 句柄 数 、Socket 连接 数 、Connection 数 、Channel 
数 、 内 存 信息 等 。 总 体 上 来 说 ，RabbitMQ Management 插件 提供 的 监控 页 面 是 相对 完善 的 ， 在 
实际 应 用 中 具有 很 高 的 使 用 价值 。 但 是 有 一 个 遗憾 就 是 其 难以 和 公司 内 部 系统 平台 关联 ， 对 于 
业务 资源 的 使 用 情况 、 相 应 的 预防 及 告警 的 联动 无 法 顺利 贯通 。 如 果 在 人 力 、 物 力 等 条 件 允 许 
的 情况 下 ， 自 定义 一 套 监控 系统 非常 有 必要 。 


7.5.4 通过 HTTP API 接口 提供 监控 数据 


那么 监控 数据 从 哪里 来 呢 ? RabbitMQ Management 插件 不 仅 提供 了 一 个 优秀 的 Web 管理 界 
面 ， 还 提供 了 HTTP API 接口 以 供 调用 。 下 面 以 集群 、 交 换 器 和 队列 这 3 个 角度 来 阐述 如 何 通 
过 HTTP API 获取 监控 数据 。 


假设 集群 中 一 共有 4 个 节点 nodel node2. node3 和 node4， 有 一 个 交换 器 exchange 通过 
同一 个 路 由 键 “rk” 绑 定 了 3 个 队列 queuel. queue2 和 queue3. 


下 面 首先 收集 集群 节点 的 信息 ， 集 群 节点 的 信息 可 以 通过 /api/nodes 接口 来 获取 。 有 关 
从 /api/nodes 接口 中 获取 到 数据 的 结构 可 以 参考 附录 B， 其 中 包含 了 很 多 的 数据 统计 项 ， 可 
以 挑选 感 兴趣 的 内 容 进 行 数据 收集 。 


集群 节点 信息 统计 数据 项 示例 如 代码 清单 7-7 所 示 。 
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public class ClusterNode { 

private long diskFree;// 磁 盘 空 闲 

private long diskFreeLimit; 

private long fdUsed;// 句 柄 使 用 数 

private long fdTotal; 

private long socketsUsed;//Socket 使 用 数 
private long socketsTotal; 

private long memoryUsed;// 内 存 使 用 值 
private long memoryLimit; 

private long procUsed;//Erlang 进程 使 用 数 
private long procTotal; 

GOverride 

public String toString() ( 


) 


return "(disk free-"4diskFree*", "+ 
"disk free limit-"«diskFreeLimits", "+ 
"fd used-"«fdUsed*", "+ 
"fd total-"4fdTotal*", "+ 
"sockets used-"-*socketsUsed*", "+ 
"sockets total-"*socketsTotal*", "+ 
"mem used-"4rmemoryUsed-", "+ 
"mem limit-"*memoryLimit*", "+ 
"proc used-"«4procUsed*", "+ 
"proc total-"-*procTotal-*"]"; 


// 省 略 Getter 和 Setter 方法 


在 真正 读 取 /api/nodes 接口 获取 数据 之 前 ， 我 们 还 需要 做 一 些 准 备 工 作 ， 比 如 使 用 
org.apache.commons.httpclient.HttpClient 对 HTTP GET 方法 进行 封装 , 方便 后 续 





程序 直接 调用 。 相 关 示 例如 代码 清单 7-8 所 示 。 





public class HttpUtils { 
public static String httpGet(String url, String username, String password) 
throws IOException ( 
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HttpClient client = new HttpClient(); 
client.getState().setCredentials (AuthScope.ANY, 

new UsernamePasswordCredentials (username, password)); 
GetMethod getMethod = new GetMethod (url); 
int ret = client.executeMethod (getMethod); 
String data = getMethod.getResponseBodyAsString(); 
System.out.println (data); 
return data; 
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) 


之 后 就 是 真正 获取 集群 节点 的 数据 了 ， 通 过 HTTP GET 方法 获取 http://xxx.xxx.Xxx.xxx: 
15672/api/nodes 的 JSON 数据 ， 然 后 通过 GSON 进行 解析 ， 之 后 即 可 采集 到 感 兴趣 的 数据 项 。 
GSON 的 解析 过 程 是 根据 获取 的 JSON 的 数据 格式 进行 相应 的 编码 的 ， 这 里 需要 注意 的 是 不 同 
的 版 本 有 可 能 会 有 略微 的 变动 。 示例 代 码 如 代码 清单 7-9 所 示 (注意 在 这 里 调用 HTTP API 接口 
来 获取 数据 时 都 是 需要 用 户 名 和 密码 认证 的 )。 


oa 








public static List<ClusterNode> getClusterData(String ip, int port, 
String username, String password) ( 
List«ClusterNode» list = new ArrayList«ClusterNode»(); 
String url = "http://" + ip + ":" + port + "/api/nodes"; 
System.out.println (url); 
try ( 


String urlData = HttpUtils.httpGet(url, username, password); 
parseClusters (urlData, list); 

} catch (IOException e) { 
e.printStackTrace(); 

) 

System.out.println(list); 

return list; 

) 
private static void parseClusters(String urlData, List«ClusterNode» list) ( 

JsonParser parser - new JsonParser(); 

JsonArray jsonArray = (JsonArray) parser.parse(urlData); 

for(int i-0;i«jsonArray.size();i*-*) ( 
JsonObject jsonObjectTemp = jsonArray.get(i).getAsJsonObject(); 
ClusterNode cluster = new ClusterNode(); 
cluster.setDiskFree(jsonObjectTemp.get("disk free").getAsLong()); 
cluster.setDiskFreeLimit(jsonObjectTemp. get("disk free limit"). 

getAsLong()); 

cluster.setFdUsed(jsonObjectTemp.get("fd used").getAsLong()); 
cluster.setFdTotal(jsonObjectTemp.get("fd total").getAsLong()); 
cluster.setSocketsUsed(jsonObjectTemp.get ("sockets used"). getAsLong()); 
cluster.setSocketsTotal (jsonObjectTemp.get ("sockets total").getAsLong()); 
cluster.setMemoryUsed(jsonObjectTemp.get ("mem used").getAsLong()); 
cluster.setMemoryLimit (jsonObjectTemp.get ("mem limit").getAsLong()); 
cluster.setProcUsed(jsonObjectTemp.get ("proc used").getAsLong()); 
cluster.setProcTotal(jsonObjectTemp.get ("proc total").getAsLong()); 
list.add(cluster); 
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数据 采集 完 之 后 并 没有 结束 ， 图 7-10 中 简单 囊括 了 从 数据 采集 到 用 户 使 用 的 过 程 。 首 先 采 
集 程 序 通过 定时 调用 HTTP API 接口 获取 JSON 数据 , 然后 进行 JSON 解析 之 后 再 进行 持久 化 处 
理 。 对 于 这 种 基于 时 间 序 列 的 数据 非常 适合 使 用 OpenTSDB' 来 进行 存储 。 监 控 管理 系统 可 以 根 
据 用 户 的 检索 条 件 来 从 OpenTSDB 中 获取 相应 的 数据 并 展示 到 页 面 之 中 。 监 控 管 理 系统 本 身 还 
可 以 具备 报表 、 权 限 管理 等 功能 ， 同 时 也 可 以 实时 读 取 所 采集 的 数据 ， 对 其 进行 分 析 处 理 ， 对 
于 异常 的 数据 需要 及 时 报告 给 相应 的 人 员 。 


2 y http:/hoocxxoooo0oc 15672/api/inodes 





图 7-10 ”从 数据 采集 到 用 户 使 用 的 过 程 


对 于 集群 的 各 节点 信息 展示 可 以 参考 下 方 ， 图 7-11 展示 了 各 个 节点 实时 的 内 存 占 用 情况 ， 
7-12 展示 了 各 个 节点 实时 的 磁盘 使 用 情况 。 


内 存 占用 
MB 





13:00 13:10 13:20 13:30 13:40 13:50 14:00 


7-11 各 个 节点 实时 的 内 存 占 用 情况 


É OpenTSDB: 基于 Hbase 的 分 布 式 的 ， 可 伸缩 的 时 间 序列 数据 库 。 主 要 用 途 就 是 做 监控 系统 ， 比 如 收集 大 规模 集群 (包括 网 
络 设备 、 操 作 系统 、 应 用 程序 ) 的 监控 数据 并 进行 存储 、 查 询 。 
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磁盘 剩余 空间 
cB 





13:00 13:10 13:20 13:30 13:40 13:50 14:00 


图 7-12 各 个 节点 实时 的 磁盘 使 用 情况 


对 于 交换 器 而 言 的 数据 采集 可 以 调用 /api/exchanges/vhost/name 接口 ， 比 如 需要 调 
用 虚拟 主机 为 默认 的 “/” 交换 器 名 称 为 exchange 的 数据 ， 只 需要 使 用 HTTP GET 方法 获取 
http://xxx.xxx.Xxx.Xxx:15672/api/exchanges/%2F/exchange 的 数据 即 可 。 注 意 ， 这 里 需要 将 “/” 进 
fT HTML 转 义 成 “%2F”， 否则 会 出 错 。 对 应 的 数据 内 容 可 以 参考 下 方 : 

{ 


"message stats": { 
"publish in details": ( 
"rate": 0.4// 数 据 流 入 的 速率 
}s 
"publish in": 9,// 数 据 流入 的 总 量 
"publish out details": { 
"rate": 1.2// 数 据 流 出 的 速率 
), 
"publish out": 27// 数 据 流出 的 总 量 
}, 
"outgoing": [], 
"incoming": [], 
"arguments": (], 
"internal": false, 
"auto delete": false, 
"durable": true, 


"type": "direct", 
"vhost": Tm 
"name": "exchange" 


) 


对 于 1 个 交换 器 绑 定 3 个 队列 的 情况 ， 向 交换 器 发 送 1 条 消息 ， 那 么 流入 就 是 1 条 ， 而 流 
出 就 是 3 条 。 在 应 用 的 时 候 根据 实际 情况 挑选 数据 流入 速率 或 者 数据 流出 速率 作为 发 送 数 量 ， 
以 及 挑选 数据 流入 的 量 还 是 数据 流出 的 量 作为 发 送 量 。 

相应 的 示例 详情 如 代码 清单 7-10 所 示 。 
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public class Exchange { 
private double publishInRate; 
private long publishIn; 
private double publishOutRate; 
private long publishOut; 
GOverride 
public String toString() ( 
return "(publish in rate-" + publishInRate + 
", publish in-" t+ publishIn + 
", publish out rate-" + publishOutRate + 
", publish out-" + publishOut-*"]"; 
} 
// B Getter 和 Setter 方法 
} 


public class ExchangeMonitor { 
public static void main(String[] args) { 
try { 
getExchangeData("192.168.0.2", 15672, "root", "root123", "/", 
"exchange"); 
) catch (IOException e) ( 
e.printStackTrace(); 


) 
public static Exchange getExchangeData (String ip, int port, String username, 
String password, String vhost, String exchange) throws IOException { 
String url = "http://" + ip + ":" + port * "/api/exchanges/" 
+ encode (vhost, "UTF-8") + "/" + encode (exchange, "UTF-8"); 
System.out.println(url); 
String urlData = HttpUtils.httpGet(url, username, password); 
System.out.println(urlData); 
Exchange exchangeAns = parseExchange (urlData); 
System.out.println (exchangeAns); 
return exchangeAns; 
) 
private static Exchange parseExchange(String urlData) {// 解 析 程序 
Exchange exchange - new Exchange(); 
JsonParser parser - new JsonParser(); 
JsonObject jsonObject = (JsonObject) parser.parse(urlData); 
JsonObject msgStats - 
jsonObject.get("message stats").getAsJsonObject(); 
double publish in details rate - 
msgStats.get("publish in details").getAsJsonObject ().get ("rate") 
.getAsDouble(); 
double publish out details rate - 
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msgStats.get("publish out details"). 
getAsJsonObject().get("rate").getAsDouble(); 
long publish in - msgStats.get("publish in").getAsLong(); 
long publish out - msgStats.get("publish out").getAsLong(); 
exchange.setPublishInRate (publish in details rate); 
exchange.setPublishOutRate (publish out details rate); 
exchange.setPublishIn(publish in); 
exchange.setPublishOut (publish out); 
return exchange; 


} 


对 于 队列 而 言 的 数据 采集 相关 的 接口 为 /api/queues/vhost/name， 对 应 的 数据 结构 可 
以 参考 下 方 内 容 。 同 时 参考 前 面 的 内 容 进 行 相应 的 编码 逻辑 ， 这 里 就 留 给 读者 自行 思考 。 
{ 


"consumer details": [], 
"Xnooming"s [ly 
"deliveries": [], 
"messages details": ( "rate": 0 ], 
"messages": 12, 
"messages unacknowledged details": ( "rate": 0 }, 
"messages unacknowledged": 0, 
"messages ready details": ( "rate": 0 ], 
"messages ready": 12, 
"reductions details": ( "rate": 0 }, 
"reductions": 577759, 
"message stats": ( "publish details": ( "rate": 0 ), "publish": 12 ], 
"node": "rabbitQ8node2", 
"arguments": (), 
"exclusive": false, 
"auto delete": false, 
"durable": true, 
"yhosttes qj, 
"name": "queuel", 
"message bytes paged out": 0, 
"messages paged out": O0, 
"backing queue status": { 
"mode": "default", "ql": Q0, "q2": 0, 
"delta": ["delta", "undefined", 0, 0, "undefined" ], 
"q3": 0, "q4": 12, "len"; 12, "target ram count": "infinity", 
"next seq id": 12, 
"avg ingress rate": 0.0501007133625864, 
"avg egress rate": 0, "mirror seen": 0, 
"avg ack ingress rate": 0, "avg ack egress rate": 0, 
"mirror senders": 0 
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"head message timestamp": null, 
"message bytes persistent": 28, 
"message bytes ram": 28, 
"message bytes unacknowledged": 0, 
"message bytes ready": 28, 
"message bytes": 28, 
"messages persistent": 12, 
"messages unacknowledged ram": 0, 
"messages ready ram": 12, 
"messages ram": 12, 
"garbage collection": ( 
"minor gcs": 492, "fullsweep after": 65535, "min heap size": 233, 
"min bin vheap size": 46422, "max heap size": 0 
} ， 


"state": "running", 


"recoverable slaves": [ "rabbitG8nodel" ], 
"synchronised slave nodes": [ "rabbit8nodel" ], 
"slave nodes":.[ "rabbit8nodel" ], 


"memory": 143272, 

"consumer utilisation": null, 
"consumers": 0, 

"exclusive consumer tag": null, 
"policy": "policy1" 


7.5. ”通过 客户 端 提供 监控 数据 


除了 HTTP API 接口 可 以 提供 监控 数据 ，Java 版 客户 端 (3.6.x 版 本 开始 ) 中 Channel 接 
口中 也 提供 了 两 个 方法 来 获取 数据 。 方 法 定义 如 下 : 


/** 

* Returns the number of messages in a queue ready to be delivered 
to consumers. This method assumes the queue exists. If it doesn't, 
an exception will be closed with an exception. 

QGparam queue the name of the queue 
QGreturn the number of messages in ready state 

* (throws IOException Problem transmitting method. 

*/ 
long messageCount(String queue) throws IOException; 

/** 

* Returns the number of consumers on a queue. 

* This method assumes the queue exists. If it doesn't, 

* an exception will be closed with an exception. 


+ + + + 
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* (iparam queue the name of the queue 

* (ireturn the number of consumers 

* Qthrows IOException Problem transmitting method. 

kj 

long consumerCount(String queue) throws IOException; 

messageCount (String queue) 用 来 查询 队列 中 的 消息 个 数 ， 可 以 为 监控 消息 堆积 的 情 
况 提 供 数 据 。consumerCount (String queue) 用 来 查询 队列 中 的 消费 者 个 数 ， 可 以 为 监控 
消费 者 的 情况 提供 数据 。 相 应 的 监控 视图 可 以 参考 图 7-13 和 图 7-14。 

消息 堆积 量 
Ed 












2017-08-23 19:30:37.847 
9 WWAN: 62 071.00 


90k 
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7-13 ”监控 消息 堆积 量 


18:00 18:30 19:00 19:30 20:00 20:30 21:00 
7-4 ”监控 消费 者 实例 数 
除了 这 两 个 方法 , 也 可 以 通过 连接 的 状态 进行 监控 。Java 客户 端 中 Connection 接口 提供 
Į addBlockedListener(BlockedListener listener) 方 法 (用 来 监听 连接 阻塞 信息 ) 


和 addShutdownListener (ShutdownListener listener) 方法 (用 来 监听 连接 关闭 
信息 )。 相 关 示 例如 代码 清单 7-11 所 示 。 








try ( 
Connection connection = connectionFactory.newConnection(); 
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connection.addShutdownListener(new ShutdownListener() { 
public void shutdownCompleted (ShutdownSignalException cause) { 
// 处 理 并 记录 连接 关闭 事项 
} 
); 
connection.addBlockedListener (new BlockedListener() ( 
public void handleBlocked(String reason) throws IOException ( 
// 处 理 并 记录 连接 阻塞 事项 
) 
public void handleUnblocked() throws IOException ( 
// 处 理 并 记录 连接 阻塞 取消 事项 


DE 
Channel channel = connection.createChannel(); 
long msgCount = channel.messageCount ("queuel"); 
long consumerCount - channel.consumerCount ("queuel"); 
/ /'id3K msgCount 和 consumerCount 
) catch (IOException e) ( 
e.printStackTrace(); 
) catch (TimeoutException e) { 
e.printStackTrace(); 


) 


用 户 客户 端 还 可 以 自行 定义 一 些 数据 进行 埋 点 ， 比 如 客户 端 成 功 发 送 的 消息 个 数 和 发 送 失 
败 的 消息 个 数 ， 进 一 步 可 以 计算 发 送 消息 的 成 功率 等 。 相 应 的 代码 示例 如 代码 清单 7-12 所 示 。 


d m 









public static volatile int successCount = 0;// 记 录 发 送 成 功 的 次 数 


0;// 记 录 发 送 失败 的 次 数 


public static volatile int failureCount 
// 下 面 代码 内 容 包 含 在 某 方法 体内 
try ( 
channel.confirmSelect(); 
channel.addReturnListener(new ReturnListener() ( 
public void handleReturn(int replyCode, String replyText, 
String exchange, String routingKey, AMQP 
.BasicProperties properties, byte[] body) throws IOException { 
failureCount-t*; 


}); 
channel.basicPublish("","",true,MessageProperties.PERSISTENT TEXT PLAIN, 
"msg".getBytes()); 


if (channel.waitForConfirms() == true) { 
successCount-t*; 

) else ( 
failureCount-4-*; 
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) catch (IOException e) ( 
e.printStackTrace(); 
failureCount-**; 

) catch (InterruptedException e) ( 
e.printStackTrace(); 
failureCount-**; 


) 


上 面 的 代码 中 只 是 简单 地 对 successCount 和 failureCount 进行 累加 操作 , 这 里 推荐 
引入 metrics 工具 (比如 com. codahale.metrics.*) 来 进行 埋 点 ， 这 样 既 方 便 又 高 效 。 同 
样 的 方式 也 可 以 统计 消费 者 消费 成 功 的 条 数 和 消费 失败 的 条 数 ， 这 个 就 留 给 读者 自行 思考 。 


7.5.8 1&3 RabbitMQ 服务 是 否 健康 


不 管 是 通过 HTTP API 接口 还 是 客户 端 ， 获 取 的 数据 都 是 以 作 监 控 视图 之 用 ， 不 过 这 一 切 
都 基于 RabbitMQ 服务 运行 完好 的 情况 下 。 虽 然 可 以 通过 某 些 其 他 工具 或 方法 来 检测 RabbitMQ 
进程 是 否 在 运行 (如 ps aux | grep rabbitmq), 或 者 5672 端口 是 否 开启 (如 telnet 
XXX.XXX.XXX.Xxx 5672)， 但 是 这 样 依 旧 不 能 真正 地 评判 RabbitMQ 是 否 还 具备 服务 外 部 请 
求 的 能 力 。 这 里 就 需要 使 用 AMQP 协议 来 构建 一 个 类 似 于 TCP 协议 中 的 Ping 的 检测 程序 。 当 
这 个 测试 程序 与 RabbitMQ 服务 无 法 建立 TCP 协议 层面 的 连接 , 或 者 无 法 构建 AMQP 协议 层面 
的 连接 ， 再 或 者 构建 连接 超时 时 ， 则 可 判定 RabbitMQ 服务 处 于 异常 状态 而 无 法 正常 为 外 部 应 
用 提供 相应 的 服务 。 示 例 程序 如 代码 清单 7-13 所 示 。 





/** 
* AMQP-ping 测试 程序 返回 的 状态 
f 


enum PING STATUS( 
OK, // 正 常 
EXCEPTION/ / F% 
} 


public class AMQPPing { 
private static String host - "localhost"; 
private static int port - 5672; 
private static String vhost - "/"; 
private static String username - "guest"; 
private static String password = "guest"; 
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/** 
* 读 取 rmq cfg.properties 中 的 内 容 ， 如 果 没 有 配置 相应 的 项 则 采用 默认 值 
*y 
static { 
Properties properties = new Properties (); 
try { 
properties.load(AMOPPing.class.getClassLoader(). 
getResourceAsStream("rmq cfg.properties")); 
host = properties.getProperty ("host"); 
port = Integer.valueOf (properties.getProperty("port")); 
vhost = properties.getProperty("vhost"); 
username - properties.getProperty ("username"); 
password = properties.getProperty ("password"); 
) catch (Exception e) { 
e.printStackTrace(); 
} 
} 
/** 


* AMQP-ping 测试 程序 ， 如 有 IOException 或 者 TimeoutException， 则 说 明 RabbitMQ 
* 服务 出 现 异常 情况 
Ey 
public static PING STATUS checkAMQPPing (){ 
PING STATUS ping status - PING STATUS.OK; 
ConnectionFactory connectionFactory - new ConnectionFactory(); 
connectionFactory.setHost (host); 
connectionFactory.setPort (port); 
connectionFactory.setVirtualHost (vhost); 
connectionFactory.setUsername (username); 
connectionFactory.setPassword (password); 
Connection connection = null; 
Channel channel - null; 
try ( 
connection = connectionFactory.newConnection(); 
channel = connection.createChannel(); 
) catch (IOException | TimeoutException e ) ( 
e.printStackTrace(); 
ping status - PING STATUS.EXCEPTION; 
) finally ( 
if (connection !- null) { 
tey 1 
connection.close(); 
) catch (IOException e) { 
e.printStackTrace(); 
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) 
return ping status; 
) 
} 


示例 中 涉及 rmq cfg.properties 配置 文件 ， 这 个 文件 用 来 灵活 地 配置 与 RabbitMQ 服 
务 的 连接 所 需 的 连接 信息 ， 包 括 P 地址、 端口 号、vhost、 用 户 名 和 密码 等 。 如 果 没 有 配置 相应 
的 项 则 可 以 采用 默认 的 值 。 


监控 应 用 时 ， 可 以 定时 调用 AMOPPing.checkAMQPPing () 方 法 来 获取 检测 信息 , 方法 返回 
值 是 一 个 枚 举 类 型 ， 示 例 中 只 具备 两 个 值 ， PING_STATUS .OK 和 PING STATUS .EXCEPTION， 
分 别 代表 RabbitMQ 服务 正常 和 异常 的 情况 ， 这 里 可 以 根据 实际 应 用 情况 来 细 分 返回 值 的 粒度 。 


AMQPPing 这 个 类 能 够 检测 RabbitMQ 是 否 能 够 接收 新 的 请 求 和 构造 AMQP 信道 ， 但 是 要 
检测 RabbitMQ 服务 是 否 健康 还 需要 进一步 的 措施 。 值 得 庆幸 的 是 RabbitMQ Management 插件 
提供 了 /api/aliveness-test/vhost ff] HTTP API 形式 的 接口 ， 这 个 接口 通过 3 个 步骤 来 
验证 RabbitMQ 服务 的 健康 性 : 

(1) 创建 一 个 以 “aliveness-test” 为 名 称 的 队列 来 接收 测试 消息 。 

(2) 用 队列 名 称 ， 即 “aliveness-test” 作 为 消息 的 路 由 键 ， 将 消息 发 往 默认 交换 器 。 

(3) 到 达 队 列 时 就 消费 该 消息 ， 否 则 就 报错 。 

这 个 HTTP API 接口 背后 的 检测 程序 也 称 之 为 aliveness-test， 其 运行 在 Erlang 虚拟 机 内 部 ， 
因此 它 不 会 受到 网 络 问题 的 影响 。 如 果 在 虚拟 机 外 部 ， 则 网 络 问题 可 能 会 阻止 外 部 客户 端 连接 
到 RabbitMQ 的 5672 端口 。aliveness-test 程序 不 会 删除 创建 的 队列 ， 对 于 频繁 调用 这 个 接口 的 
情况 , 它 可 以 避免 数 以 千 计 的 队列 元 数据 事务 对 Mnesia 数据 库 造 成 巨大 的 压力 。 如 果 RabbitMQ 
服务 完好 ， 调 用 /api/aliveness-test/vhost 接口 会 返回 {"status":"ok"}，HTTP 状 
态 码 为 200。 示 例 程序 如 代码 清单 7-14 所 示 。 


p» 





/** 
* AlivenessTest 程序 返回 的 状态 
* OK 表示 健康 ，EXCEPTION 表示 异常 
*f 
enum ALIVE STATUS( 
OK, 
EXCEPTION 
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} 
public class AlivenessTest { 
public static ALIVE_STATUS checkAliveness (String url, String username, String 
password) { 
ALIVE_STATUS alive_status = ALIVE_STATUS.OK; 
HttpClient client = new HttpClient(); 
client.getState().setCredentials (AuthScope.ANY, 
new UsernamePasswordCredentials (username, password)); 
GetMethod getMethod = new GetMethod (url); 
String data - null; 
int ret = -1; 
try 1 
ret = client.executeMethod (getMethod); 
data = getMethod.getResponseBodyAsString(); 
if (ret !- 200 || !data.equals("(M"status V": NV"okN")")) ( 
alive status = ALIVE STATUS.EXCEPTION; 
} 
} catch (IOException e) { 
e.printStackTrace(); 
alive status - ALIVE STATUS.EXCEPTION; 
} 
return alive_status; 
} 
} 
// 调 用 示例 
//AlivenessTest.checkAliveness ("http://192.168.0.2: 
//15672/api/aliveness-test/$2F", 
/["roG0t", "robti23"); 


监控 应 用 时 ， 可 以 定时 调用 AlivenessTest.checkAliveness () 方 法 来 获取 检测 信息 ， 
方法 返回 值 是 一 个 枚 举 类 型 ， 示 例 中 只 具备 两 个 值 : ALIVE STATUS.OK 和 
ALIVE STATUS .EXCEPTION， 分 别 代表 RabbitMQ 服务 正常 和 异常 的 情况 ， 这 里 可 以 根据 实 
际 应 用 情况 来 细 分 返回 值 的 粒度 。 


这 里 的 aliveness-test 程序 配合 前 面 的 AMQPPing 程序 一 起 使 用 可 以 从 内 部 和 外 部 这 两 个 方 
面 来 全 面 地 监控 RabbitMQ 服务 。 表 5-2 中 还 提 及 另外 两 个 接口 /api/healthchecks/node 
和 /api/healthchecks/node/node， 这 两 个 HTTP API 接口 分 别 表示 对 当前 节点 或 指定 节 
点 进行 基本 的 健康 检查 ,包括 RabbitMQ 应 用 、 信 道 、 队 列 是 否 运行 正常 ， 是 否 有 告警 产生 等 。 
使 用 方式 可 以 参考 /api/aliveness-test/vhost， 在 此 不 再 赣 述 。 


e 202 è 


98 7 &  RabbitMO 运 维 


7.5.A ”元 数据 管理 与 监控 








确保 RabbitMQ 能 够 健康 运行 还 不 足以 让 人 放松 警惕 。 考 虑 这 样 一 种 情况 : 小 明 为 小 张 创 
建 了 一 个 队列 并 绑 定 了 一 个 交换 器 ， 之 后 某 人 由 于 疏 忽而 阴 差 阳 错 地 删除 了 这 个 队列 而 无 人 得 
知 ， 最 后 小 张 在 使 用 这 个 队列 的 时 候 就 会 报 出 “NOT FOUND” 的 错误 。 如 果 这 些 在 测试 环境 
中 发 生 ， 那 么 还 可 以 弥补 。 在 实际 生产 环境 中 ， 如 果 误 删 了 一 个 队列 ， 必 然 会 造成 不 可 估计 的 
影响 。 此 时 业务 方 如 果 正 在 使 用 这 个 队列 ， 正 常情 况 下 会 立刻 报 出 异常 ， 相 关 人 员 可 以 迅速 做 
出 动作 以 尽 可 能 地 降低 影响 。 试 想 如 果 是 一 个 定时 任务 调用 此 队列 ， 并 在 深夜 3 点 执行 相应 的 
逻辑 ， 此 时 报 出 异常 想必 也 会 对 相关 人 员 造 成 不 小 的 精神 骚扰 。 


不 止 删除 队列 这 一 个 方面 ， 还 有 删除 了 一 个 交换 器 ， 或 者 修改 了 绑 定 信息 ， 再 或 者 是 胡乱 
建立 了 一 个 队列 绑 定 到 现 有 的 一 个 交换 器 中 ， 同 时 又 没有 消费 者 订阅 消费 此 队列 ， 从 而 留 下 消 
息 堆 积 的 隐患 等 都 会 对 使 用 RabbitMQ 服务 的 业务 应 用 造成 影响 。 所 以 对 于 RabbitMQ 元 数据 的 
管理 与 监控 也 尤为 重要 。 


许多 应 用 场景 是 在 业务 逻辑 代码 中 创建 相应 的 元 数据 资源 〈 交 换 器 、 队 列 及 绑 定 关 系 ) 并 
使 用 。 对 于 排他 的 、 自 动 删 除 的 这 类 非 高 可 靠 性 要 求 的 元 数据 资源 可 以 在 一 定 程度 上 忽略 元 数 
据 变更 的 影响 。 但 是 对 于 两 个 非常 重要 的 且 通 过 消息 中 间 件 交互 的 业务 应 用 ， 在 使 用 相应 的 元 
数据 资源 时 最 好 进行 相应 的 管控 ， 如 果 一 方 或 者 其 他 方 肆意 变更 所 使 用 的 元 数据 ， 必 然 对 另 一 
方 造成 不 小 的 损失 。 管 控 的 介入 自然 会 降低 消息 中 间 件 的 灵活 度 , 但 是 可 以 增强 系统 的 可 靠 性 。 
比如 通过 专用 的 “元 数据 审核 系统 ”来 配置 相应 的 元 数据 资源 ， 提 供给 业务 方 使 用 的 用 户 只 有 
可 读 和 可 写 的 权限 ， 这 样 可 以 进一步 降低 风险 。 


非 管控 的 元 数据 可 以 天 马 行 室 ， 业 务 方 可 以 在 这 一 时 刻 创 建 ， 下 一 时 刻 就 删除 ， 对 其 监控 
也 无 太 大 的 意义 。 对 于 管控 的 元 数据 来 说 ， 监 控 的 介入 就 会 有 意义 也 会 有 必要 很 多 。 虽 然 对 于 
只 有 可 读 写 权 限 的 用 户 不 能 够 变更 元 数据 信息 ， 也 难免 会 被 其 他 具有 可 配置 权限 的 超级 用 户 臭 
改 。RabbitMQ 中 在 创建 元 数据 资源 的 时 候 是 以 一 种 声明 的 形式 完成 的 ， 无 则 创建 、 有 则 不 变 ， 
不 过 在 对 应 的 元 数据 存在 的 情况 下 ， 对 其 再 次 声明 时 使 用 不 同 的 属性 会 报 出 相应 的 错误 信息 。 
我 们 可 以 利用 这 一 特性 来 监控 元 数据 的 变更 ， 通 过 定时 程序 来 将 记录 中 的 元 数据 信息 重新 声明 
一 次 ， 查 看 是 否 有 异常 报 出 。 不 过 这 种 方法 非常 具有 局 限 性 ， 只 能 增加 元 数据 的 信息 而 不 能 减 
少 。 比 如 有 一 个 队列 没有 消费 者 且 以 后 也 不 会 被 使 用 ， 我 们 对 其 进行 了 解 绑 操 作 ， 这 样 就 没有 
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更 多 的 消息 流入 而 造成 消息 堆积 ， 不 过 这 一 变更 由 于 某 些 局 限 性 没有 及 时 将 记录 变更 以 通知 到 
那个 定时 程序 ， 此 时 又 重新 将 此 队列 绑 定 到 原 交换 器 中 。 


这 里 列举 一 个 简单 的 元 数据 管控 和 监控 的 示例 来 应 对 此 种 情况 ， 此 系统 并 非 最 优 ， 但 可 以 
给 读者 在 实际 应 用 时 提供 一 种 解决 对 应 问题 的 思路 。 


如 图 7-15 所 示 ， 所 有 的 业务 应 用 都 需要 通过 元 数据 审核 系统 来 申请 创建 〈 当 然 也 可 以 包含 
查询 、 修 改 及 删除 ) 相应 的 元 数据 信息 。 在 申请 动作 完成 之 后 ， 由 专门 的 人 员 进行 审批 ， 之 后 
在 数据 库 中 存储 和 在 RabbitMQ 集群 中 创建 相应 的 元 数据 ， 这 两 个 步骤 可 以 同时 进行 ， 而 且 也 
无 须 为 这 两 个 动作 添加 强 一 致 性 的 事务 逻辑 。 在 数据 库 和 RabbitMQ 集群 之 间 会 有 一 个 元 数据 
一 致 性 校 验 程序 来 检测 元 数据 不 一 致 的 地 方 ， 然 后 将 不 一 致 的 数据 上 送 到 监控 管理 系统 。 监 控 
管理 系统 中 可 以 显示 元 数据 不 一 致 的 记录 信息 ， 也 可 以 以 告警 的 形式 推送 出 来 ， 然 后 相应 的 管 
理 人 员 可 以 选择 手动 或 者 自动 地 进行 元 数据 修正 。 这 里 的 不 一 致 有 可 能 是 由 于 数据 库 的 记录 未 
被 正确 及 时 地 更 新 , 也 有 可 能 是 RabbitMQ 集群 中 元 数据 被 异常 算 改 。 元 数据 修正 需 慎 之 又 慎 ， 
在 整个 系统 修正 逻辑 完备 之 前 ， 建 议 优先 采用 人 工 的 方式 ， 毕 竟 不 一 致 的 元 数据 仅 占 少数 ， 人 
工 修正 的 工作 量 并 不 太 大 。 





图 7-15 元 数据 审核 系统 
RabbitMQ 的 元 数据 可 以 很 顺利 地 以 表 的 形式 记录 在 数据 库 中 , 参考 附录 A, 主要 的 元 数据 
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是 queues、exchanges 和 bindings， 可 以 分 别 建立 三 张 表 。 

+ Table 1: 队列 信息 表 ， 名 称 为 rmq queues。 列 名 有 name, vhost, durable, 
auto delete.arguments.cluster name、 description, 其 中 name、 durable, 
auto delete. arguments 可 以 参考 3.2.2 节 中 的 内 容 。vhost 表示 虚拟 主机 。 
cluster name 表示 队列 所 在 的 集群 名 称 , 毕竟 一 般 一 个 公司 所 用 的 RabbitMQ 集群 并 非 
只 有 一 个 。description 是 相应 的 描述 信息 ， 相 当 于 备注 ， 通 常 可 置 为 空 。 

* Table 2: 交 换 器 信息 表 , 名 称 为 rmq_exchanges。 列 名 有 name, vhost.type.durable, 
auto_delete、\internal\arguments\cluster_name\description 其 中 name's 
type. durable. auto delete. internal. arguments 可 参考 3.2.1 节 中 的 内 容 。 
vhost, cluster name 和 description 可 参考 Table 1. 


* Table 3: 绑 定 信息 表 , 名 称 为 rmq bindings. 列 名 有 source, vhost, destinations 
destination type.routing key.arguments.cluster name,.description. 
其 中 source. vhost, destination, destination type. routing key. 
arguments 可 以 参考 323 节 和 3.2.4 节 中 的 内 容 。vhost、cluster name 和 
description 可 参考 Table 1. 


元 数据 一 致 性 检测 程序 可 以 通过 /api/definitions 的 HTTP API 接口 获取 集群 的 元 数 
据 信 息 ， 通 过 解析 之 后 与 数据 库 中 的 记录 一 一 比 对 ， 查 看 是 否 有 不 一 致 的 地 方 。 可 以 参考 7.5.3 
节 的 风格 ， 具 体 的 实现 示例 就 留 着 读者 自己 动手 实践 了 。 


7.6 小 结 


RabbitMQ 作为 一 个 成 熟 的 消息 中 间 件 , 不 仅 要 为 应 用 提供 强大 的 功能 支持 , 也 要 能 够 维护 
自身 状态 的 稳定 ， 而 这 个 维护 就 需要 强大 的 运 维 层 面 的 支撑 。 运 维 本 身 就 是 一 个 大 学 问 ， 涵 盖 
多 方面 的 内 容 ， 比 如 容量 评估 、 资 源 分 配 、 集 群 管控 、 系 统 调 优 、 升 级 扩容 、 故 障 修复 、 监 控 
告警 、 负 载 均衡 等 。 本 章 从 最 基本 的 集群 搭建 开始 到 故障 修复 ， 从 集群 迁移 再 到 集群 监控 ， 并 
不 要 求 能 解决 所 有 RabbitMQ 的 运 维 问题 ， 希 望 能 够 在 多 个 层面 为 读者 提供 解决 问题 的 方法 和 
思路 。 
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RabbitMQ 可 以 通过 3 种 方式 实现 分 布 式 部 署 : 集群 、Federation 和 Shovel. iX 3 种 方式 不 
是 互 斥 的 ， 可 以 根据 需要 选择 其 中 的 一 种 或 者 以 几 种 方式 的 组 合 来 达到 分 布 式 部 署 的 目的 。 
Federation 和 Shovel 可 以 为 RabbitMQ 的 分 布 式 部 署 提供 更 高 的 灵活 性 ,但 同时 也 提高 了 部 署 的 
复杂 性 。 


本 章 主要 阐述 Federation 与 Shovel 的 相关 的 原理 、 用 途 及 使 用 方式 等 。 最 后 在 小 结 部 分 中 
将 集群 与 Federation/Shovel 的 部 署 方式 进行 对 比 区 分 ， 以 加 深 对 相关 知识 点 的 理解 。 
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8.1 Federation 





Federation 插件 的 设计 目标 是 使 RabbitMQ 在 不 同 的 Broker 节 点 之 间 进 行 消息 传递 而 无 须 建 
立 集群 ， 该 功能 在 很 多 场景 下 都 非常 有 用 : 

仿 Federation 插件 能 够 在 不 同 管理 域 (可 能 设置 了 不 同 的 用 户 和 vhost， 也 可 能 运行 在 不 同 
版 本 的 RabbitMQ 和 Erlang 上 ) 中 的 Broker 或 者 集群 之 间 传 递 消 息 。 

信 Federation 插件 基于 AMQP 0-9-1 协议 在 不 同 的 Broker 之 间 进 行 通信 ， 并 设计 成 能 够 容 
忍 不 稳定 的 网 络 连接 情况 。 

* 一 个 Broker 节点 中 可 以 同时 存在 联邦 交换 器 (或 队列 ) 或 者 本 地 交换 器 (或 队列 )， 只 
需要 对 特定 的 交换 器 (或 队列 ) 创建 Federation 连接 (Federation link). 


+ Federation 不 需要 在 W 个 Broker 节点 之 间 创 建 O(N”) 个 连接 (尽管 这 是 最 简单 的 使 用 方 
式 )， 这 也 就 意味 着 Federation 在 使 用 时 更 容易 扩展 。 


Federation 插件 可 以 让 多 个 交换 器 或 者 多 个 队列 进行 联邦 。 一 个 联邦 交换 器 federated 
exchange) 或 者 一 个 联邦 队列 (federated queue) 接收 上 游 (upstream) 的 消息 ， 这 里 的 上 游 是 
指 位 于 其 他 Broker 上 的 交换 器 或 者 队列 。 联 邦交 换 器 能 够 将 原本 发 送 给 上 游 交 换 器 Cupstream 
exchange) 的 消息 路 由 到 本 地 的 某 个 队列 中 ， 联 邦 队列 则 允许 一 个 本 地 消费 者 接收 到 来 自 上 游 
队列 Cupstream queue) 的 消息 。 


为 了 能 够 详细 解释 Federation, 我 们 先 从 架构 来 分 析 联 邦交 换 器 和 联邦 队列 , 之 后 再 来 讲解 
如 何 使 用 Federtation。 


8.1.1 联邦 交换 器 


假设 图 8-1 中 brokerl 部 署 在 北京 ，broker2 部 署 在 上 海 ， 而 broker3 部 署 在 广州 ， 彼 此 之 间 
相距 其 远 ， 网 络 延 迟 是 一 个 不 得 不 面 对 的 问题 。 
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图 8-1 联邦 交换 器 


有 一 个 在 广州 的 业务 ClientA 需要 连接 broker3， 并 向 其 中 的 交换 器 exchangeA 发 送 消息 ， 
此 时 的 网 络 延迟 很 小 ，ClientA 可 以 迅速 将 消息 发 送 至 exchangeA 中 ， 就 算 在 开启 了 publisher 
confirm 机 制 或 者 事务 机 制 的 情况 下 ， 也 可 以 迅速 收 到 确认 信息 。 此 时 又 有 一 个 在 北京 的 业务 
ClientB 需要 向 exchangeA 发 送 消息 ， 那 么 ClientB 与 broker3 之 间 有 很 大 的 网 络 延 迟 ，ClientB 
将 发 送 消息 至 exchangeA 会 经 历 一 定 的 延迟 ， 尤 其 是 在 开启 了 publisher confirm 机 制 或 者 事务 
机 制 的 情况 下 ，ClientB 会 等 待 很 长 的 延迟 时 间 来 接收 broker3 的 确认 信息 ， 进 而 必然 造成 这 条 
发 送 线程 的 性 能 降低 ， 甚 至 造成 一 定 程度 上 的 阻塞 。 

那么 要 怎么 优化 业务 ClientB 呢 ? 将 业务 ClientB 部 署 到 广州 的 机 房 中 可 以 解决 这 个 问题 ， 
但 是 如 果 ClientB 调用 的 另 一 些 服务 都 部 署 在 北京 ， 那 么 又 会 引发 新 的 时 延 问 题 ， 总 不 见得 将 
所 有 业务 全 部 部 署 在 一 个 机 房 ， 那 么 容 灾 又 何以 实现 ? 这 里 使 用 Federation 插件 就 可 以 很 好 地 
解决 这 个 问题 。 

如 图 8-2 所 示 ， 在 broker3 中 为 交换 器 exchangeA (broker3 中 的 队列 queueA 通过 “rkA” 
与 exchangeA 进行 了 绑 定 ) 与 广州 的 brokerl 之 间 建 立 一 条 单 向 的 Federation link. HER} Federation 
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插件 会 在 broker! 上 会 建立 一 个 同名 的 交换 器 exchangeA (这 个 名 称 可 以 配置 ， 默 认同 名 )， 同 
时 建立 一 个 内 部 的 交换 器 “exchangeA 一 broker3 B”， 并 通过 路 由 键 “rkA” 将 这 两 个 交换 器 绑 定 
起 来 。 这 个 交换 器 “exchangeA 一 broker3 B” 名 字 中 的 “broker3 ”是 集群 名 ， 可 以 通过 
rabbitmqctl set cluster name {new_name} 命 令 进行 修改 。 与 此 同时 Federation 插件 
还 会 在 brokerl 上 建立 一 个 队列 “federation: exchangeA — broker3 B”， 并 与 交换 器 “exchangeA 
一 broker3 B” 进 行 绑 定 。Federation 插件 会 在 队列 “federation: exchangeA — broker3 B” 5j broker3 
中 的 交换 器 exchangeA 之 间 建 立 一 条 AMQP 连接 来 实时 地 消费 队列 “federation: exchangeA 一 
broker3 B” 中 的 数据 。 这 些 操 作 都 是 内 部 的 ， 对 外 部 业务 客户 端 来 说 这 条 Federation link 建立 在 
brokerl 的 exchangeA 和 broker3 的 exchangeA 之 间 。 


name= exchangeA -> broker3 B 
type = x-federation-upstream 
arguments z[x-max-hops:1; x- 
downstream-name:broker3 x- 
internal-purpose-federation]) 
durable = true 

auto-delete = true 

internal = true 


Federation link 


name = federation: exhangea b broker3 B 
arguments = bentermakpurposs : federation) 





8-2 Æx Federation link 


回 到 前 面 的 问题 ， 部 署 在 北京 的 业务 ClientB 可 以 连接 brokerl 并 向 exchangeA 发 送 消息 ， 
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这 样 ClientB 可 以 迅速 发 送 完 消息 并 收 到 确认 信息 ， 而 之 后 消息 会 通过 Federation link 转发 到 
broker3 的 交换 器 exchangeA 中 。 最 终 消 息 会 存 入 与 exchangeA 绑 定 的 队列 queueA 中 ， 消 费 者 
最 终 可 以 消费 队列 queueA 中 的 消息 。 经 过 Federation link 转发 的 消息 会 带 有 特殊 的 headers 属 
性 标记 。 例 如 向 brokerl 中 的 交换 器 exchangeA 发 送 一 条 内 容 为 “federation test payload.” 的 持 
久 化 消息 ， 之 后 可 以 在 broker3 中 的 队列 queueA 中 消费 到 这 条 消息 ， 详 细 如 图 8-3 所 示 。 
Exchange 
Routing Key 
Redelivered 


Properties delivery_mode: 2 
headers: x-received-from: uri: amqp://192.168.0.2:5672 


exchange: exchangeA 
redelivered: false 
duster-name: broker1 


Payload , 
23 bytes | federation test payload 


Encoding: string 





8-3 ”消息 的 内 容 


Federation 不 仅 便利 于 消息 生产 方 ， 同 样 也 便利 于 消息 消费 方 。 假 设 某 生产 者 将 消息 存 入 
broker! 中 的 某 个 队列 queueB， 在 广州 的 业务 ClientC 想 要 消费 queueB 的 消息 ， 消 息 的 流转 及 
确认 必然 要 忍受 较 大 的 网 络 延迟 ， 内 部 编码 逻辑 也 会 因 这 一 因素 变 得 更 加 复杂 ， 这 样 不 利于 
ClientC 的 发 展 。 不 如 将 这 个 消息 转发 的 过 程 以 及 内 部 复杂 的 编程 逻辑 交 给 Federation 去 完成 ， 
而 业务 方 在 编码 时 不 必 再 考虑 网 络 延迟 的 问题 。Federation 使 得 生产 者 和 消费 者 可 以 异地 部 署 而 
又 让 这 两 方 感受 不 到 过 多 的 差异 。 


图 8-2 中 brokerl 的 队列 “federation: exchangeA -> broker3 B” 是 一 个 相对 普通 的 队列 ， 可 
以 直接 通过 客户 端 进行 消费 。 假 设 此 时 还 有 一 个 客户 端 ClientD 通过 Basic.Consume 来 消费 
队列 “federation: exchangeA— broker3 B” 的 消息 ， 那 么 发 往 brokerl 中 exchangeA 的 消息 会 有 
一 部 分 (一 半 ) 被 ClientD 消费 掉 ， 而 另 一 半 会 发 往 broker3 的 exchangeA。 所 以 如 果 业 务 应 用 
有 要 求 所 有 发 往 brokerl 中 exchangeA 的 消息 都 要 转发 至 broker3 的 exchangeA 中 ， 此 时 就 要 注 
意 队 列 “federation: exchangeA — broker3 B” 不 能 有 其 他 的 消费 者 ， 而 对 于 “异地 均 挫 消 费 ” 这 
种 特殊 需求 ， 队 列 “federation: exchangeA — broker3 B” 这 种 天 生 特 性 提供 了 支持 。 对 于 brokerl 
的 交换 器 exchangeA 而 言 ， 它 是 一 个 普通 的 交换 器 ， 可 以 创建 一 个 新 的 队列 绑 定 它 ， 对 它 的 用 
法 没有 什么 特殊 之 处 。 
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如 图 8-4 所 示 ， 一 个 federated exchange 同样 可 以 成 为 男 一 个 交换 器 的 upstream exchange. 
同样 如 图 8-5 所 示 ， 两 方 的 交换 器 可 以 互 为 federated exchange 和 upstream exchange。 其 中 参数 
“max_hops=1 ”表示 一 条 消息 最 多 被 转发 的 次 数 为 1。 










upstream exchange 
broker1 
ederated exchange 


broker2 


federatedexchange 
broker3 


8-4 federated exchange 成 为 另 一 个 交换 器 的 upstream exchange 


Producerl ~ Producer2 





Consumer1 Consumer2 


8-5 两 方 的 交换 器 互 为 federated exchange 和 upstream exchange 
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需要 特别 注意 的 是 ， 对 于 默认 的 交换 器 〈 每 个 vhost 下 都 会 默认 创建 一 个 名 为 “” 的 交换 
器 ) 和 内 部 交换 器 而 言 ， 不 能 对 其 使 用 Federation 的 功能 。 

对 于 联邦 交换 器 而 言 ， 还 有 更 复杂 的 拓扑 逻辑 部 署 方 式 。 比 如 图 8-6 H “fan-out” HEX 
树 形式 ， 或 者 图 8-7 中 “三 足 易 立 ”的 情形 。 






max, hopszno of levels-1 


图 8-6 “fan-out” 的 多 叉 树 
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图 8-7 “ZERI” 
还 有 环形 的 拓扑 部 署 ， 如 图 8-8 所 示 。 关 于 更 多 的 拓扑 部 署 就 留 给 读者 自行 思考 了 。 





8-8 环形 的 拓扑 部 署 
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8.1.2 ”联邦 队列 


除了 联邦 交换 器 ，RabbitMQ 还 可 以 支持 联邦 队列 〈federated queue)。 联 邦 队 列 可 以 在 多 个 
Broker 节点 〈 或 者 集群 ) 之 间 为 单个 队列 提供 均衡 负载 的 功能 。 一 个 联邦 队列 可 以 连接 一 个 或 者 多 
个 上 游 队 列 〈upstream queue)， 并 从 这 些 上 游 队列 中 获取 消息 以 满足 本 地 消费 者 消费 消息 的 需求 。 


8-9 演示 了 位 于 两 个 Broker 中 的 几 个 联邦 队列 (灰色 ) 和 非 联邦 队列 (白色 )。 队 列 queuel 
和 queue2 原本 在 broker2 中 , 由 于 某 种 需求 将 其 配置 为 federated queue 并 将 brokerl 作为 upstream。 
Federation 插件 会 在 brokerl 上 创建 同名 的 队列 queuel 和 queue2， 与 broker2 中 的 队列 queuel 和 
queue2 分 别 建 立 两 条 单 向 独立 的 Federation link。 当 有 消费 者 ClinetA 连接 broker2 并 通过 
Basic.Consume 消费 队列 queuel (或 queue2) 中 的 消息 时 ， 如 果 队 列 queuel (或 queue2) 中 
本 身 有 若干 消息 堆积 ， 那 么 ClientA 直接 消费 这 些 消 息 ， 此 时 broker2 中 的 queuel (或 queue2 ) 
并 不 会 拉 取 brokerl 中 的 queuel (或 queue2) 的 消息 ; 如 果 队 列 queuel (3X queue2) 中 没有 消息 
堆积 或 者 消息 被 消费 完了 ,那么 它 会 通过 Federation link 拉 取 在 broker! 中 的 上 游 队列 queuel (或 
queue2) 中 的 消息 (如 果 有 消息 )， 然 后 存储 到 本 地 ， 之 后 再 被 消费 者 ClientA 进行 消费 。 


Upstream Downstream 


queuel 


Message Flow 


Message Flow 


queue4 


ERN 


broker2 


queue3 


LL 


brokeri 





[5] Bi & b federated queue 口 白色 为 unfederated queue 


8-9 ”联邦 队列 
消费 者 既 可 以 消费 broker2 中 的 队列 ， 又 可 以 消费 brokerl 中 的 队列 ，Federation 的 这 种 分 
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布 式 队 列 的 部 署 可 以 提升 单个 队列 的 容量 。 如 果 在 brokerl 一 端 部 署 的 消费 者 来 不 及 消费 队列 
queuel 中 的 消息 ， 那 么 broker2 一 端 部 署 的 消费 者 可 以 为 其 分 担 消 费 ， 也 可 以 达到 某 种 意义 上 
的 负载 均衡 。 


和 federated exchange 不 同 , 一 条 消息 可 以 在 联邦 队列 间 转 发 无 限 次 。 如 图 8-10 中 两 个 队列 
queue 互 为 联邦 队列 。 


broker1 broker2 





E 8-10 互 为 联邦 队列 


队列 中 的 消息 除了 被 消费 ， 还 会 转向 有 多 余 消费 能 力 的 一 方 ， 如 果 这 种 “多 余 的 消费 能 
JJ" f£ brokerl 和 broker2 中 来 回 切 换 ， 那 么 消费 也 会 在 brokerl 和 broker2 中 的 队列 queue 中 
来 回转 发 。 


可 以 在 其 中 一 个 队列 上 发 送 一 条 消息 “msg” 然 后 再 分 别 创建 两 个 消费 者 ClientB 和 ClientC 
分 别 连 接 brokerl 和 broker2， 并 消费 队列 queue 中 的 消息 ， 但 是 并 不 需要 确认 消息 (消费 完 消 
息 不 需要 调用 Basic.Ack)。 来 回 开启 /关闭 ClientB 和 ClientC 可 以 发 现 消息 “msg ”会 在 brokerl 
和 broker2 之 间 串 来 串 去 。 


8-11 中 的 broker2 的 队列 queue 没有 消息 堆积 或 者 消息 被 消费 完 之 后 并 不 能 通过 
Basic.Get 来 获取 brokerl 中 队列 queue 的 消息 。 因 为 Basic.Get 是 一 个 异步 的 方法 ， 如 果 要 从 
brokerl 中 队列 queue 拉 取 消息 ， 必 须要 阻塞 等 待 通过 Federation link 拉 取 消息 存 入 broker2 中 的 队 
Ji] queue 之 后 再 消费 消息 ， 所 以 对 于 federated queue 而 言 只 能 使 用 Basic.Consume 进行 消费 。 


federated queue 并 不 具备 传递 性 。 考 虑 图 8-11 的 情形 ， 队 列 queue2 作为 federated queue 与 
队列 queuel 进行 联邦 ,而 队列 queue2 又 作为 队列 queue3 的 upstream queue, 但 是 这 样 队 列 queuel 
与 queue3 之 间 并 没有 产生 任何 联邦 的 关系 。 如 果 队 列 queuel 中 有 消息 堆积 , 消费 者 连接 broker3 
消费 queue3 中 的 消息 ， 无 论 queue3 处 于 何 种 状态 ， 这 些 消费 者 都 消费 不 到 queuel 中 的 消息 ， 
除非 queue2 有 消费 者 。 
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broker3 





图 8-11 联邦 队列 的 传递 性 
注意 要 点 : 


理论 上 可 以 将 一 个 federated queue 与 一 个 federated exchange 绑 定 起 来 ， 不 过 这 样 会 导致 一 
些 不 可 预测 的 结果 ， 如 果 对 结果 评估 不 足 ， 建 议 慎 用 这 种 搭配 方式 。 


8.1.3 Federation 的 使 用 


为 了 能 够 使 用 Federation 功能 ， 需 要 配置 以 下 2 个 内 容 : 


(1) 需要 配置 一 个 或 多 个 upstream， 每 个 upstream 均 定义 了 到 其 他 节点 的 Federation link。 
这 个 配置 可 以 通过 设置 运行 时 的 参数 (Runtime Parameter) 来 完成 ， 也 可 以 通过 federation 
management 插件 来 完成 。 


(2) 需要 定义 匹配 交换 器 或 者 队列 的 一 种 /多 种 策略 (Policy). 


Federation 插件 默认 在 RabbitMQ 发 布 包 中 ， 执 行 rabbitmq-plugins enable 
rabbitmq federation 命令 可 以 开启 Federation 功能 ， 示 例如 下 : 


[root@nodel ~]# rabbitmq-plugins enable rabbitmq federation 
The following plugins have been enabled: 
amqp client 
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rabbitmq federation 
Applying plugin configuration to rabbit8nodel... started 2 plugins. 


由 前 面 的 讲解 可 知 ，Federation 内 部 基于 AMQP 协议 拉 取 数据 ， 所 以 在 开启 
rabbitmq federation 插件 的 时 候 ， 默 认 会 开启 amqp client 插件 。 同 时 ， 如 果 要 开启 
Federation 的 管理 插件 ， 需 要 执行 rabbitmq-plugins enable rabbitmq federation 
management 命令 ， 示 例如 下 : 


[root@nodel ~]# rabbitmq-plugins enable rabbitmq federation management 
The following plugins have been enabled: 

cowlib 

cowboy 

rabbitmq web dispatch 

rabbitmq management agent 

rabbitmq management 

rabbitmq federation management 
Applying plugin configuration to rabbit@nodel... started 6 plugins. 


开启 rabbitmq federation management 插件 之 后 ， 在 RabbitMQ 的 管理 界面 中 
“Admin” 的 右 侧 会 多 出 “Federation Status” 和 “Federation Upstreams” 两 个 Tab 页 ， 如 图 8-12 
所 示 : 

Users 


Virtual Hosts 
Policies 


Federation Status 


Federation Upstreams 


8-12 Federation 的 Tab 页 





rabbitmq federation management 插件 依附 于 rabbitmq management 插件 ， 所 


以 开启 rabbitmq federation management 插件 的 同时 默认 也 会 开启 rabbitmq_ 
management 插件 。 


注意 要 点 : 
当 需 要 在 集群 中 使 用 Federation 功能 的 时 候 , 集群 中 所 有 的 节点 都 应 该 开启 Federation 插件 。 


有 关 Federation upstream 的 信息 全 部 都 保存 在 RabbitMQ 的 Mnesia 数据 库 中 ， 包 括 用 户 信 
息 、 权 限 信 息 、 队 列 信息 等 。 在 Federation 中 存在 3 种 级 别 的 配置 。 
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(1) Upstreams: f" upstream 用 于 定义 与 其 他 Broker 建立 连接 的 信息 。 

(2) Upstream sets: 每 个 upstream set 用 于 对 一 系列 使 用 Federation 功能 的 upstream 进 
行 分 组 。 

(3) Policies: 每 一 个 Policy 会 选 定 出 一 组 交换 器 ， 或 者 队列 ， 亦 或 者 两 者 皆 有 而 进行 
限定 ， 进 而 作用 于 一 个 单独 的 upsteam 或 者 upstream set 之 上 。 


实际 上 , 在 简单 使 用 场景 下 , 基本 上 可 以 忽略 upstream set 的 存在 , 因为 存在 一 种 名 为 “all” 
并 且 隐 式 定义 的 upstream set， 所 有 的 upstream 都 会 添加 到 这 个 set 之 中 。Upstreams 和 
Upstream sets 都 属于 运行 时 参数 ， 就 像 交 换 器 和 队列 一 样 ， 每 个 vhost 都 持 有 不 同 的 参数 
和 策略 的 集合 。 有 关 运 行 时 参数 和 策略 的 更 多 信息 ， 可 以 参考 第 6.3 节 的 内 容 。 


Federation 相关 的 运行 时 参数 和 策略 都 可 以 通过 下 面 3 种 方式 进行 设置 : 
(1) 通过 rabbitmqctl LK. 
(2) 通过 RabbitMQ Management 插件 提供 的 HITPAPI 接口 ， 详 细 参 考 第 5.6 节 。 


(3) 通过 rabbitmq federation management 插件 提供 的 Web 管理 界面 的 方式 〈 最 
方便 且 通 用 )。 不 过 基于 Web 管理 界面 的 方式 不 能 提供 全 部 功能 ， 比 如 无 法 针对 upstream set 进 
行 管理 。 

下 面 就 详细 讲解 如 何 正 确 地 使 用 Federation 插件 ， 首 先 以 图 8-2 中 brokerl (IP 地 址 : 
192.168.0.2) 和 broker3 (IP 地 址 : 192.168.0.4) 的 关系 来 讲述 如 何 建 立 federated exchange. 

第 一 步 

需要 在 broker! 和 broker3 中 开启 rabbitmq federation 插件 ， 最 好 同时 开启 


rabbitmq federation management 插件 。 
第 二 步 
在 broker3 中 定义 一 个 upstream。 


第 一 种 是 通过 rabbitmqctl 工具 的 方式 ， 详 细 如 下 : 


rabbitmqctl set parameter federation-upstream f1 
'("uri":"amqp://root:root1230192.168.0.2:5672", "ack-mode":"on-confirm"]' 


第 二 种 是 通过 调用 HTTP API 接口 的 方式 ， 详 细 如 下 : 
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curl =i. -u root:root123 -XPUT -d 

'("value":("uri":"amqp://root:root1230192.168.0.2:5672", "ack-mode":"on-confi 
xui") t 

http://192.168.0.4:15672/api/parameters/federation-upstream/$2f/f1 


第 三 种 是 通过 在 Web 管理 界面 中 添加 的 方式 , 在 “Admin” 一 “Federation Upstreams" 一 
“Add a new upstream” 中 创建 ， 可 参考 图 8-13。 


各 个 参数 的 含义 如 下 , 插 号 中 对 应 的 是 采用 设置 Runtime Parameter 或 者 调用 HTTP API 
接口 的 方式 所 对 应 的 相关 参数 名 称 。 


Name: 
URI: (?) 
Prefetch count: (?) 
Reconnect delay: (?) 


Acknowledgement Mode: (^) | Onconfum —— 





Trust User-ID: (?) [Ne — 


Federated exchanges parameters 
Exchange: (?) 
Max hops: (7) | 
Expires: (?) 
Message TTL: (?) 
HA Policy: (?) 


Federated queues parameter 


Queue: (?) 





图 8-13 参数 设置 
通用 的 参数 如 下 所 述 。 
€ Name: 定义 这 个 upstream 的 名 称 。 必 填 项 。 
$ URI (uri): $E X upstream 的 AMQP 连接 。 必 填 项 。 本 示例 中 可 以 填写 为 
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amqp://root:root123(2)192.168.0.2:5672.. 


* Prefetch count (prefetch count): X Federation 内 部 缓存 的 消息 条 数 ， 即 
在 收 到 上 游 消 息 之 后 且 在 发 送 到 下 游 之 前 缓存 的 消息 条 数 。 


+ Reconnect delay (reconnect-delay): Federation link 由 于 某 种 原因 断 开 之 后 ， 
需要 等 待 多 少 秒 开始 重新 建立 连接 。 


€ Acknowledgement Mode (ack-mode): 定义 Federation link 的 消息 确认 方式 。 共 
有 3 种 : on-confirm、on-publish、no-ack。 默 认为 on-confirm， 表 示 在 接收 
到 下 游 的 确认 消息 (等 待 下 游 的 Basic.Ack) 之 后 再 向 上 游 发 送 消息 确认 ， 这 个 选项 
可 以 确保 网 络 失败 或 者 Broker 宕 机 时 不 会 丢失 消息 ， 但 也 是 处 理 速度 最 慢 的 选项 。 如 
果 设 置 为 on-publish， 则 表示 消息 发 送 到 下 游 后 〈 并 需要 等 待 下 游 的 Basic.Ack) 
再 向 上 游 发 送 消 息 确认 ,这 个 选项 可 以 确保 在 网 络 失败 的 情况 下 不 会 丢失 消息 , 但 不 能 
确保 Broker 宕 机 时 不 会 丢失 消息 。no-ack 表示 无 须 进行 消息 确认 ， 这 个 选项 处 理 速 
度 最 快 ， 但 也 最 容易 丢失 消息 。 


4 Trust User-ID (trust-user-id): 设 定 Federation 是 否 使 用 “Validated User-ID” 这 
个 功能 。 如 果 设 置 为 false 或 者 没有 设置 ， 那 么 Federation 会 忽略 消息 的 user_id 这 个 属 
性 ， 如 果 设 置 为 tue， 则 Federation HERR user_id 为 上 游 任意 有 效 的 用 户 的 消息 。 


所 谓 的 “Validated User-ID” 功 能 是 指 发 送 消息 时 验证 消息 的 user_id 的 属性 ， 在 3.3 节 
中 讲 到 channel.basicPublish 方法 中 有 个 参数 是 BasicProperties ， 这 个 
BasicProperties 类 中 有 个 属性 为 userId。 可 以 通过 如 下 的 方法 设置 消息 的 user id 属 
性 为 “root”: 


AMQP.BasicProperties properties = new AMQP.BasicProperties(); 
properties.setUserId("root"); 
channel.basicPublish("amq.fanout", "", properties, "test user id".getBytes()); 


如 果 在 连接 Broker 时 所 用 的 用 户 名 为 “root”, 24 A 3€" test user id” 这 条 消息 时 设置 的 user id 
的 属性 为 “guest”， 那 么 这 条 消息 会 发 送 失 败 ， 具 体 报错 为 406 PRECONDITION FAILED - 
user id property set to 'guest' but authenticated user was root， 只 有 当 user_id 设置 为 “root” 时 
这 条 消息 才 会 发 送 成 功 。 


只 适合 federated exchange 的 参数 如 下 所 述 。 


e 220 * 


第 8 章 跨越 集群 的 界限 


信 Exchange (exchange): 指定 upstream exchange 的 名 称 ， 默 认 情况 下 和 federated 
exchange 同名 ， 即 图 8-2 中 的 exchangeA。 


信 Max hops (max-hops): 指定 消息 被 丢弃 前 在 Federation link 中 最 大 的 跳 转 次 数 。 默 
认为 1。 注 意 即 使 设置 max-hops 参数 为 大 于 1 的 值 ,同一 条 消息 也 不 会 在 同一 个 Broker 
中 出 现 2 次 ， 但 是 有 可 能 会 在 多 个 节点 中 被 复制 。 


* Expires (expires) :指定 Federation link 断 开 之 后 ,federated queue 所 对 应 的 upstream 
queue( 即 图 8-2 中 的 队列 “federation: exchangeA — broker3 B”) 的 超时 时 间 , 默认 为 ‘none”， 
表示 为 不 删除 ， 单 位 为 ms。 这 个 参数 相当 于 设置 普通 队列 的 x-expires 参数 。 设 置 
这 个 值 可 以 避免 Federation link 断 开 之 后 ， 生 产 者 一 直 在 向 broker! 中 的 exchangeA 发 
送 消息 ， 这 些 消息 又 不 能 被 转发 到 broker3 中 而 被 消费 掉 ， 进 而 造成 brokerl 中 有 大 量 
的 消息 堆积 。 


* Message TTL (message-ttl): 为 federated queue 所 对 应 的 upstream queue (HJ 
图 8-2 中 的 队列 “federation: exchangeA — broker3 B") 设置 ， 相 当 于 普通 队列 的 
x-message-ttl 参数 。 默 认为 “none” 表示 消息 没有 超时 时 间 。 


* HA policy (ha-policy): X federated queue 所 对 应 的 upstream queue 〈 即 图 8-2 中 
的 队列 “federation: exchangeA— broker3 B”) 设置 ， 相 当 于 普通 队列 的 x-ha-policy 
参数 ， 默 认为 “none”， 表 示 队 列 没 有 任何 HA。 


只 适合 federated queue 的 参数 如 下 所 述 。 


Queue (queue): 执行 upstream queue 的 名 称 ， 默 认 情 况 下 和 federated queue 同名 ， 可 以 
参考 图 8-10 中 的 queue。 


第 三 步 
定义 一 个 Policy 用 于 匹配 交换 器 exchangeA， 并 使 用 第 二 步 中 所 创建 的 upstream。 


第 一 种 是 通过 rabbitmqctl 工具 的 方式 ， 如 下 “定义 所 有 以 “exchange” 开 头 的 交换 器 
作为 federated exchange ): 


rabbitmqctl set policy --apply-to exchanges pl "^exchange" '("federation- 
upstream":"f1")' 


第 二 种 是 通过 HTTP API 接口 的 方式 ， 如 下 : 
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curl =i =u root;rootl23 -XPUT -d 

'("pattern":"^exchange","definition":("federation-upstream":"f1"),"apply-to" 
:"exchanges"]' 

http://192.168.0.4:15672/api/policies/$2F/pl 


第 三 种 是 通过 在 Web 管理 界面 中 添加 的 方式 , 在 “Admin” — "Policies" — "Add/ update 
apolicy” 中 创建 ， 可 参考 图 8-14。 


* Add / update a policy 
Name: pi 
Pattern: ^exchange 


: 
Apply to: | 
Priority: 


Definition: federarcion-upscream -|fi 


HA HA mode (?) | HÀ params (?) | HA sync mode (?) 
Federation Federation upstream set (?) | Federation upstream (?) 


Queues Message TTL | Auto expire | Max length | Max length bytes 
Dead letter exchange | Dead letter routing key | Lazy mode 


Exchanges Alternate exchange 





图 8-14 通过 Web 管理 界面 方式 添加 


这 样 就 创建 了 一 个 Federation link, 可 以 在 Web 管理 界面 中 “Admin” 一 “Federation Status” 
一 “Running Links” 查 看 到 相应 的 链接 。 


还 可 以 通过 rabbitmqctl eval 'rabbit federation status:status().' 命 令 
来 查看 相应 的 Federation link。 示 例如 下 : 


[root@node2 ~]# rabbitmqctl eval 'rabbit federation status:status().' 
[[{exchange, <<"exchangeA">>}, 
(upstream exchange,<<"exchangeA">>}, 
(type,exchange], 
(vhost,c««"/"»»), 
(upstream,««"f1"»»5], 
(id,««"fad51c1713586d453b7dc9cd1a28641192a94£41"»»], 
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{status, running}, 

{local connection,<<"<rabbit@node2.1.15217.10>">>}, 
(uri,««"amqp://192.168.0.2:5672"»»), 
(timestamp,((2017,10,15),(0,7,48))])]] 


对 于 federated queue 的 建立 ， 首 先 同样 也 是 定义 一 个 upstream。 之 后 定义 Policy 的 时 候 略 
微 有 变化 , 比如 使 用 rabbitmqctl 工具 的 情况 (定义 所 有 以 “queue” 开 头 的 队列 作为 federated 
queue): 


rabbitmqctl set policy --apply-to queues p2 "^queue" '("federation-upstream":"f1")] 


通常 情况 下 ， 针 对 每 个 upstream 都 会 有 一 条 Federation link, i Federation link 对 应 到 一 
个 交换 器 上 。 例 如 ，3 个 交换 器 与 2 个 upstream 分 别 建 立 Federation link 的 情况 下 ,会 有 6 
条 连接 。 


8.2 Shovel 


与 Federation 具备 的 数据 转发 功能 类 似 ，Shovel 能 够 可 靠 、 持 续 地 从 一 个 Broker 中 的 队列 
(作为 源 端 , 即 sourco ) 拉 取 数 据 并 转发 至 另 一 个 Broker 中 的 交换 器 (作为 目的 端 , 即 destination) 
作为 源 端 的 队列 和 作为 目的 端的 交换 器 可 以 同时 位 于 同一 个 Broker 上 ， 也 可 以 位 于 不 同 的 
Broker 上 。Shovel 可 以 翻译 为 “铲子 ”， 是 一 种 比较 形象 的 比喻 ， 这 个 “铲子 ”可 以 将 消息 从 一 
方 “ 挖 到” 另 一 方 。Shovel 的 行为 就 像 优秀 的 客户 端 应 用 程序 能 够 负责 连接 源 和 目的 地 、 负 责 
消息 的 读 写 及 负责 连接 失败 问题 的 处 理 。 


Shovel 的 主要 优势 在 于 : 


D MIRE o Shovel 可 以 移动 位 于 不 同 管理 域 中 的 Broker( 或 者 集群 ) 上 的 消息 , 这 些 Broker 
(或 者 集群 ) 可 以 包含 不 同 的 用 户 和 vhost, 也 可 以 使 用 不 同 的 RabbitMQ 和 Erlang 版 本 。 


€ 支持 广域网 。Shovel 插件 同样 基于 AMQP 协议 在 Broker 之 间 进 行 通 信 ， 被 设计 成 可 以 
容忍 时 断 时 续 的 连通 情形 ， 并 且 能 够 保证 消息 的 可 靠 性 。 


€ 高 度 定制 。 当 Shove 成 功 连接 后 ， 可 以 对 其 进行 配置 以 执行 相关 的 AMQP 命令 。 
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8.2.[1 Shovel 的 原理 


图 8-15 展示 的 是 Shovel 的 结构 示意 图 这 里 一 共有 两 个 Broker:brokerl(IP 地 址 :192.168.0.2) 

和 broker2 (IP 地 址 : 192.168.0.3). broker! 中 有 交换 器 exchangel 和 队列 queue1， 且 这 两 者 通 
过 路 由 键 “rk1” 进 行 绑 定 ; broker2 中 有 交换 器 exchange2 和 队列 queue2， 且 这 两 者 通过 路 由 键 
“rk2” 进 行 绑 定 。 在 队列 queuel 和 交换 器 exchange2 之 间 配 置 一 个 Shovel link， 当 一 条 内 容 为 
“shovel test payload” 的 消息 从 客户 端 发 送 至 交换 器 exchangel 的 时 候 ， 这 条 消息 会 经 过 图 8-15 
中 的 数据 流转 最 后 存储 在 队列 queue2 中 。 如 果 在 配置 Shovel link 时 设置 了 
add forward headers 参数 为 tue， 则 在 消费 到 队列 queue2 中 这 条 消息 的 时 候 会 有 特殊 的 
headers 属性 标记 ， 详 细 内 容 可 参考 图 8-16. 





broker1 


queuel 





— mm 


8-15 Shovel 的 结构 
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Exchange 
Routing Key 
Redelivered 

Properties 


Payload 
20 bytes 
Encoding: string 
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(AMQP default) 
queue2 
o 


delivery mode: 2 
headers: x-shovelled: shovelled-by: rabbitGnode1 
shovel-type: dynamic 
shovel-name: hidden, shovel 
shovel-vhost: / 
src-uri: amqp://192.168.0.2:5672 
dest-uri: amqp://192.168.0.3:5672 
src-queue: queuel 
dest-queue: queue2 


shovel test payload. 


8-16 ”消息 的 内 容 


通常 情况 下 ， 使 用 Shovel 时 配置 队列 作为 源 端 ， 交 换 器 作为 目的 端 ， 就 如 图 8-15 一 样 。 
同样 可 以 将 队列 配置 为 目的 端 ， 如 图 8-17 所 示 。 虽 然 看 起 来 队列 queuel 是 通过 Shovel link 直 
接 将 消息 转发 至 queue2 的 ， 其 实 中 间 也 是 经 由 broker2 的 交换 器 转发 ， 只 不 过 这 个 交换 器 是 默 


认 的 交换 器 而 已 。 





8-17 ”将 队列 配置 为 目的 端 
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如 图 8-18 所 示 , 配置 交换 器 为 源 端 也 是 可 行 的 虽然 看 起 来 交换 器 exchangel 是 通过 Shovel 
link 直接 将 消息 转发 至 exchange2 上 的 , 实际 上 在 brokerl 中 会 新 建 一 个 队列 (名称 由 RabbitMQ 
自 定义 ， 比 如 图 8-18 中 的 “amq.gen-ZwolUsoUchY6a7xaPyrZZH”) 并 绑 定 exchangel， 消 息 从 
交换 器 exchangel 过 来 先 存储 在 这 个 队列 中 ， 然 后 Shovel 再 从 这 个 队列 中 拉 取 消息 进而 转发 至 
交换 器 exchange2。 


amq.gen-ZwolUsoU ^ 


chY6a7xaPyrZZH 





图 8-18 配置 交换 器 为 源 端 


前 面 所 阐述 的 brokerl 和 broker2 中 的 exchangel. queuel. exchange2 及 queue2 都 可 以 在 
Shovel 成 功 连接 源 端 或 者 目的 端 Broker 之 后 再 第 一 次 创建 (执行 一 系列 相应 的 AMQP 配置 声 
明 时 )， 它 们 并 不 一 定 需要 在 Shovel link 建立 之 前 创建 。Shovel 可 以 为 源 端 或 者 目的 端 配置 多 
个 Broker 的 地 址 ， 这 样 可 以 使 得 源 端 或 者 目的 端的 Broker 失效 后 能 够 尝试 重 连 到 其 他 Broker 
之 上 【随机 挑选 )。 可 以 设置 reconnect delay 参数 以 避免 由 于 重 连 行为 导致 的 网 络 泛 洪 ， 
或 者 可 以 在 重 连 失败 后 直接 停止 连接 。 针 对 源 端 和 目的 端的 所 有 配置 声明 会 在 重 连 成 功 之 后 被 
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8.2.2 Shovel 的 使 用 





Shovel 插件 默认 也 在 RabbitMQ 的 发 布 包 中 ， 执 行 rabbitmq-plugins enable 
rabbitmq shovel 命令 可 以 开启 Shovel 功能 ， 示 例如 下 : 


[root@node2 opt]# rabbitmq-plugins enable rabbitmq shovel 
The following plugins have been enabled: 
amqp_client 
rabbitmq shovel 
Applying plugin configuration to rabbitü8node2... started 2 plugins. 


由 前 面 的 讲解 可 知 ，Shovel 内 部 也 是 基于 AMQP 协议 转发 数据 的 ， 所 以 在 开启 
rabbitmq shovel 插件 的 时 候 , 默认 也 会 开启 amqp client 插件 。 同 时 , 如 果 要 开启 Shovel 
的 管理 插件 ， 需 要 执行 rabbitmq-plugins enable rabbitmq shovel management 命 
令 ， 示 例如 下 : 


[root@node2 opt]# rabbitmq-plugins enable rabbitmq shovel management 
The following plugins have been enabled: 

cowlib 

cowboy 

rabbitmq web dispatch 

rabbitmq management agent 

rabbitmq management 

rabbitmq shovel management 
Applying plugin configuration to rabbit8node2... started 6 plugins. 


- 


开启 rabbitmq shovel management 插件 之 后 , 在 RabbitMQ 的 管理 界面 中 “Admin” 
的 右 侧 会 多 出 “Shovel Status ”和 “Shovel Management” HA Tab 页 ， 如 图 8-19 所 示 。 
rabbitmq shovel management 插件 依附 于 rabbitmq management 插件 ， 所 以 开启 
rabbitmq shovel management 插件 的 同时 默认 也 会 开启 rabbitmq management 插件 。 


Shovel Status 


Shovel Management 





8-19 Shovel 的 Tab 页 


Shovel 既 可 以 部 署 在 源 端 ， 也 可 以 部 署 在 目的 端 。 有 两 种 方式 可 以 部 署 Shove: 静态 方式 
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(static) 和 动态 方式 〈dynamic)。 静 态 方式 是 指 在 rabbitmq.config 配置 文件 中 设置 ， 而 动 
态 方式 是 指 通过 Runtime Parameter 设置 。 


静态 方式 


在 rabbitmq.config 配置 文件 中 针对 Shovel 插件 的 配置 信息 是 一 种 Erlang 项 式 ， 由 单 
条 Shovel 条 目 构 成 (shovels 部 分 的 下 一 层 ): 


(rabbitmq shovel, [ (shovels, [ {shovel name, [ ... ]), ... 1) ]} 


每 一 条 Shovel 条 目 定义 了 源 端 与 目的 端的 转发 关系 ， 其 名 称 〈shovel name) 必须 是 独 一 
无 二 的 。 每 一 条 Shovel 的 定义 都 像 下 面 这 样 : 


(shovel name, [ (sources, [ +.: ]) 
>» (destinations, [ ees ]J 
; (queue, queue name] 
7 (prefetch count, count) 
; (ack mode, a mode] 
z (publish properties, [ ... ]) 
, ipublish fields, [ ... ]) 
; {reconnect delay, reconn delay) 


其 中 sources. destination 和 queue 这 三 项 是 必需 的 ， 其 余 的 都 可 以 默认 。 对 应 于 
图 8-15 的 详细 的 Shovel 配置 如 代码 清单 8-1 所 示 。 





[(rabbitmq shovel, 


[(shovels, 
[(hidden shovel, 
[(sources, 
[(broker, "amqp://root:root12380192.168.0.2:5672"]), 
(declarations, 


[ 

('queue.declare',[(queue, ««"queuel"»»), durable]], 

('exchange.declare',[ 
(exchange, ««"exchangel"»»), 
(type, ««"direct"»»5], 
durable 

] 

), 

('queue.bind',[ 
(exchange, ««"exchangel"»»], 
(queue, ««"queuel"»»5), 
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(routing key, <<"rk1">>} 
] 
}]}]}, 
{destinations, 
[(broker, "amqp://root:root1230192.168.0.3:5672"], 
(declarations, 
[ 
('queue.declare',[(queue, ««"queue2"»»), durable]], 
('exchange.declare',[ 
(exchange, ««"exchange2"»»5), 
(type, ««"direct"»»], 
durable 
] 
}i 
('queue.bind',[ 
(exchange, ««"exchange2"»»], 
(queue, ««"queue2"»»), 
(routing key, ««"rk2"»»] 
] 
FIFI Y» 
(queue, ««"queuel"»»], 
{ack mode, no ack}, 
(prefetch count, 64], 
(publish properties, [(delivery mode, 2}]}, 
(add forward headers, true], 
(publish fields, [(exchange, ««"exchange2"»»], 
(routing key,<<"rk2">>}]}, 
(reconnect delay, 5}] 


)] 
JM 


在 代码 清单 8-1 F, sources 和 destinations 两 者 都 包含 了 同样 类 型 的 配置 : 


(sources, [ {broker[ 或 brokers], broker list) 
, (declarations, declaration list) 
]) 


其 中 broker 项 配置 的 是 URI， 定 义 了 用 于 连接 Shovel 两 端的 服务 器 地 址 、 用 户 名 、 密 
码 、vhost 和 端口 号 等 。 如 果 sources 或 者 destinations 是 RabbitMQ 集群 ， 那 么 就 使 用 
brokers, 并 在 其 后 用 多 个 URI 字符 串 以 “[]” 的 形式 包 庄 起 来 , 比如 {brokers, ["amap: // 
root:root1230192.168.0.2:5672","amqp://root:root1230192.168.0.4:5672"]) , 
这 样 的 定义 能 够 使 得 Shovel 在 主 节点 故障 时 转移 到 另 一 个 集群 节点 上 。 


declarations 这 一 项 是 可 选 的 ，declaration list 指定 了 可 以 使 用 的 AMQP 命令 的 
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列表 ， 声 明了 队列 、 交 换 器 和 绑 定 关 系 。 比 如 代码 清单 8-1 中 sources 的 declarations 这 一 项 
声明 了 队列 queue1 ( 'queue.declare' ) 交换 器 exchangel ( 'exchange.declare' ) 及 
其 之 间 的 绑 定 关系 ( 'queue.bind' ) 注意 其 中 所 有 的 字符 串 并 不 是 简单 地 用 引号 标注 ， 而 是 同 
时 用 双 尖 括号 包裹 ， 比 如 <<"queue1l">>。 这 里 的 双 尖 括号 是 要 让 Erlang 程序 不 要 将 其 视 为 简单 
的 字符 串 ,而 是 binary 类 型 的 字符 串 。 如 果 没 有 双 尖 括号 包 里 ,那么 Shovel 在 启动 的 时 候 就 会 出 错 。 
与 queuel 一 起 的 还 有 一 个 durable 参数 ， 它 不 需要 像 其 他 参数 一 样 需要 包 右 在 大 括号 内 ， 这 是 因 
为 像 durable 这 种 类 型 的 参数 不 需要 赋值 ， 它 要 么 存在 ， 要 么 不 存在 ， 只 有 在 参数 需要 赋值 的 时 
候 才 需要 加 上 大 括号 。 


与 sources 和 destinations 同 级 的 queue 表示 源 端 服务 器 上 的 队列 名 称 。 可 以 将 
queue 设置 为 “<<>>” 表示 匿名 队列 (队列 名 称 由 RabbitMQ 自动 生成 , 参考 图 8-18 中 brokerl 
的 队列 )。 


prefetch count 参数 表示 Shovel 内 部 缓存 的 消息 条 数 ， 可 以 参考 Federation 的 相关 参 
数 。Shovel 的 内 部 缓存 是 源 端 服务 器 和 目的 端 服务 器 之 间 的 中 间 缓 存 部 分 ,可 以 参考 7.4.2 节 的 
RabbitMQ ForwardMaker。 


ack mode 表示 在 完成 转发 消息 时 的 确认 模式 ， 和 Federation 的 ack mode 一 样 也 有 三 种 
取 值 : no ack 表示 无 须 任何 消息 确认 行为 ; on publish 表示 Shove 会 把 每 一 条 消息 发 送 到 
目的 端 之 后 再 向 源 端 发 送 消息 确认 ; on _confirm 表示 Shovel 会 使 用 publisher confirm 机 制 ， 
在 收 到 目的 端的 消息 确认 之 后 再 向 源 端 发 送 消息 确认 。Shovel 的 ack mode 默认 也 是 
on_confirm， 并 且 官 方 强烈 建议 使 用 该 值 。 如 果 选 择 使 用 其 他 值 ， 整 体 性 能 虽然 会 有 略微 提 
升 ， 但 是 发 生 各 种 失效 问题 的 情况 时 ， 消 息 的 可 靠 性 得 不 到 保障 。 


publish properties 是 指 消息 发 往 目的 端 时 需要 特别 设置 的 属性 列表 。 默 认 情况 下 ， 
被 转发 的 消息 的 各 个 属性 是 被 保留 的 , 但 是 如 果 在 publish properties 中 对 属性 进行 了 设 
置 则 可 以 覆盖 原先 的 属性 值 。publish properties 的 属性 列表 包括 content type. 
content encoding. headers. delivery mode. priority. correlation id. 
reply to. expiration. message id. timestamp. type. user id. app id 和 


cluster id. 


add forward headers 如 果 设置 为 tue， 则 会 在 转发 的 消息 内 添加 x-shovelled 的 
header 属性 ， 参 考 图 8-16。 
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publish fields 定义 了 消息 需要 发 往 目 的 端 服 务 器 上 的 交换 器 以 及 标记 在 消息 上 的 路 
由 键 。 如 果 交 换 器 和 路 由 键 没有 定义 ， 则 Shovel 会 从 原始 消息 上 复制 这 些 被 忽略 的 设置 。 


reconnect delay 指定 在 Shovel link 失效 的 情况 下 ， 重 新 建立 连接 前 需要 等 待 的 时 间 ， 
单位 为 秒 。 如 果 设 置 为 0， 则 不 会 进行 重 连 动作 ， 即 Shovel 会 在 首次 连接 失效 时 停止 工作 。 
reconnect delay 默认 为 5 秒 。 


动态 方式 


Lj Federation upstream 类 似 ，Shovel 动态 部 署 方 式 的 配置 信息 会 被 保存 到 RabbitMQ 的 
Mnesia 数据 库 中 ， 包 括 权 限 信 息 、 用 户 信息 和 队列 信息 等 内 容 。 每 一 个 Shovel link 都 由 一 个 相 
应 的 Parameter 定义 ， 这 个 Parameter 同样 可 以 通过 rabbitmqctl 工具 、RabbitMQ 
Management 插件 的 HTTP API 接口 或 者 rabbitmq shovel management 提供 的 Web 管理 
界面 的 方式 设置 。 


下 面 展 示 的 是 对 应 图 8-15 的 3 种 设置 Parameter 的 示例 用 法 。 
第 一 种 是 通过 rabbitmqctl 工具 的 方式 ， 详 细 如 下 : 


rabbitmqctl set parameter shovel hidden shovel \ 
'("src-uri":"amqp://root:root1230192.168.0.2:5672", 

"src-queue":"queuel", 

"dest-uri":"amqp://root:root1230192.168.0.3:5672", "src-exchange-key":"rk2", 
"prefetch-count":64, "reconnect-delay":5, "publish-properties":[], 
"add-forward-headers":true, "ack-mode":"on-confirm")"' 


第 二 种 是 通过 调用 HTTP API 接口 的 方式 ， 详 细 如 下 : 


curl =i St root:root123 -XPUT -d 

'("value":("src-uri":"amqp://root:root1230192.168.0.2:5672", "src-queue":"que 
uei", 

"dest-uri":"amqp://root:root1230192.168.0.3:5672", "src-exchange-key":"rk2", 

"prefetch-count":64, "reconnect-delay":5, "publish-properties":[], 

"add-forward-headers":true, "ack-mode":"on-confirm"])' 

http://192.168.0.2:15672/api/parameters/shovel/$2f/hidden shovel 


第 三 种 是 通过 Web 管理 界面 中 添加 的 方式 , 在 “Admin” 一 “Shovel Management" — “Add 
a new shovel” 中 创建 ， 可 参考 图 8-20。 
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v Adda new shovel 


Name: hidden shovel 
Source: URI (?) 

(amqp://root: 4 i * |queuei 
[Exchange v |©) 
man frego:  exchange2 


- (Routing key: 
rk2 


Destination: URI (?) 


Prefetch count: |64 
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Reconnect delay: | 
Q) 


"m—————— 
headers: (2) LOA "| 








Acknowledgement | 
mode: (?) | On confim 











图 8-20 通过 Web 管理 界面 添加 


在 创建 了 一 个 Shovel link 之 后 ， 可 以 在 Web 管理 界面 中 “Admin” 一 “Shovel Status" rp 
看 到 相应 的 信息 ， 也 可 以 通过 rabbitmqctl eval 'rabbit shovel status:status()."' 


命令 直接 查询 Shovel 的 状态 信息 ,该 命令 会 调用 rabbitmq_shovel 插件 模块 中 的 status 方 法 ， 
该 方法 将 返回 一 个 Erlang 列表 ， 其 中 每 一 个 元 素 对 应 一 个 已 配置 好 的 Shovel。 示 例如 下 : 


[root@nodel ~]# rabbitmqctl eval 'rabbit shovel status:status().' 
[((««"/"»»,««"hidden shovel"»»)], 

dynamic, 

(running,[(src uri,««"amqp://192.168.0.2:5672"»»), 


(dest uri,««"amqp://192.168.0.3:5672"»»)]], 
((2017,10,16],(11,41,58])]] 


列表 中 的 每 一 个 元 素 都 以 一 个 四 元 组 的 形式 构成 : {Name, Type, Status, Timestamp}。 
具体 含义 如 下 : 
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* Name 表示 Shovel 的 名 称 。 
+ Type 表示 类 型 ， 有 2 种 取 值 一 一 static 和 dynamic。 


* Status 表示 目前 Shovel 的 状态 。 当 Shovel 处 于 启动 、 连 接 和 创建 资源 时 状态 为 
starting; 当 Shovel 正常 运行 时 是 running; 当 Shovel 终止 时 是 terminated。 


V% Timestamp 表示 该 Shovel 进入 当前 状态 的 时 间 戳 ， 具 体格 式 是 {{YYYY，MM，DD)} ， 
(HH, MMS hs 


8.2.3 ”案例 : 消息 堆积 的 治理 


消息 堆积 是 在 使 用 消息 中 间 件 过 程 中 遇 到 的 最 正常 不 过 的 事情 。 消 息 堆积 是 一 把 双 刃 剑 ， 适 
量 的 堆积 可 以 有 削 峰 、 缓 存 之 用 ， 但 是 如 果 堆 积 过 于 严重 ， 那 么 就 可 能 影响 到 其 他 队列 的 使 用 ， 
导致 整体 服务 质量 的 下 降 。 对 于 一 台 普通 的 服务 器 来 说 , 在 一 个 队列 中 堆积 1 万 至 10 万 条 消息 ， 
丝毫 不 会 影响 什么 。 但 是 如 果 这 个 队列 中 堆积 超过 1 千 万 乃至 一 亿 条 消息 时 ， 可 能 会 引起 一 些 严 
重 的 问题 ， 比 如 引起 内 存 或 者 磁盘 告警 而 造成 所 有 Connection 阻塞 ， 详 细 可 以 参考 92 节 。 


消息 堆积 严重 时 ， 可 以 选择 清空 队列 ， 或 者 采用 空 消费 程序 丢弃 掉 部 分 消息 。 不 过 对 于 重 
要 的 数据 而 言 ， 丢 弃 消息 的 方案 并 无 用 武之 地 。 另 一 种 方案 是 增加 下 游 消 费 者 的 消费 能 力 ， 这 
个 思路 可 以 通过 后 期 优化 代码 逻辑 或 者 增加 消费 者 的 实例 数 来 实现 。 但 是 后 期 的 代码 优化 在 面 
临 紧急 情况 时 总 归 是 “ 远 水 解 不 了 近 渴 ” 并 且 有 些 业务 场景 也 并 非 可 以 简单 地 通过 增加 消费 实 
例 而 得 以 增强 消费 能 力 。 


在 一 筹 莫 展 之 时 ， 不 如 试 一 下 Shovel。 当 某 个 队列 中 的 消息 堆积 严重 时 ， 比 如 超过 某 个 设 
定 的 阐 值 ， 就 可 以 通过 Shovel 将 队列 中 的 消息 移交 给 另 一 个 集群 。 
如 图 8-21 所 示 ， 这 里 有 如 下 几 种 情形 。 
€ 情形 1: 当 检 测 到 当前 运行 集群 clusterl 中 的 队列 queuel 中 有 严重 消息 堆积 ， 比 如 通过 
/api/queues/vhost/name 接口 获取 到 队列 的 消息 个 数 (messages) 超过 2 T73 
或 者 消息 占用 大 小 (messages bytes) 超过 10GB 时 ， 就 启用 shovell 将 队列 queuel 
中 的 消息 转发 至 备份 集群 cluster2 中 的 队列 queue2 。 
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€ 情形 2: 紧 随 情形 1， 当 检测 到 队列 queuel 中 的 消息 个 数 低 于 1 百 万 或 者 消息 占用 大 小 
低 于 1GB 时 就 停止 shovell ， 然 后 让 原本 队列 queuel 中 的 消费 者 慢 慢 处 理 剩 余 的 堆积 。 

* 情形 3: 当 检 测 到 队列 queuel 中 的 消息 个 数 低 于 10 万 或 者 消息 占用 大 小 低 于 100MB 时 ， 
就 开启 shovel2 将 队列 queue2 中 暂 存 的 消息 返还 给 队列 queuel。 

仿 情形 4: 紧 随 情形 3， 当 检测 到 队列 queuel 中 的 消息 个 数 超过 1 百 万 或 者 消息 占用 大 小 
高 于 1GB 时 就 将 shovel2 停 掉 。 





图 8-21 消息 堆积 的 治理 


如 此 ， 队 列 queuel 就 拥有 了 队列 queue2 这 个 “保镖 ”为 它 保驾 护航 。 这 里 是 “一 备 一 ” 
的 情形 ， 如 果 需 要 要 “一 备 多 ”， 可 以 采用 镜像 队列 或 者 引入 Federation. 
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8.3 小结 


集群 是 在 第 7 章 中 一 直 在 讲述 的 一 种 部 署 方式 ， 也 是 最 为 通用 的 一 种 方式 。 集 群 将 多 个 
Broker 节点 连接 起 来 组 成 逻辑 上 独立 的 单个 Broker。 集 群 内 部 借助 Erlang 进行 消息 传输 ， 所 以 
集群 中 的 每 个 节点 的 Erlang cookie 务必 要 保持 一 致 。 同 时 ， 集 群 内 部 的 网 络 必须 是 可 靠 的 ， 
RabbitMQ 和 Erlang 的 版 本 也 必须 一 致 。 虚 拟 主机 、 交 换 器 、 用 户 、 权 限 等 都 会 自动 备份 到 集 
群 中 的 各 个 节点 。 队 列 可 能 部 署 单个 节点 或 被 镜像 到 多 个 节点 中 。 连 接 到 任意 节点 的 客户 端 能 
够 看 到 集群 中 所 有 的 队列 ， 即 使 该 队列 不 在 所 连接 的 节点 之 上 。 通 常 使 用 集群 的 部 署 方 式 来 提 
高 可 靠 性 和 吞吐 量 ， 不 过 集群 只 能 部 署 在 局 域 网 内 。 


Federation， 可 以 翻译 为 “联邦 ” Federation 可 以 通过 AMQP 协议 (可 配置 SSL) 让 原本 
发 送 到 某 个 Broker( 或 集群 ， 中 的 交换 器 或 队列 ) 上 的 消息 能 够 转发 到 另 一 个 Broker RAR 
群 ) 中 的 交换 器 (或 队列 ) 上 ， 两 方 的 交换 器 (或 队列 ) 看 起 来 是 以 一 种 “联邦 ”的 形式 在 运 
作 。 当 然 必 须要 确保 这 些 “ 联 邦 ” 的 交换 器 或 者 队列 都 具备 合适 的 用 户 和 权限 。 


联邦 交换 器 (federated exchange) 通过 单 向 点 对 点 的 连接 (Federation link) 形式 进行 通信 。 
默认 情况 下 ， 消 息 只 会 由 Federation 连接 转发 一 次 ， 可 以 允许 有 复杂 的 路 由 拓扑 来 提高 转发 次 
数 。 在 Federation 连接 上 ， 消 息 可 能 不 会 被 转发 ， 如 果 消 息 到 达 了 联邦 交换 器 之 后 路 由 不 到 合 
适 的 队列 , 那么 它 也 不 会 被 再 次 转发 到 原来 的 地 方 (这 里 指 上 游 交 换 器 , 即 upstream exchange). 
可 以 通过 Federation 连接 广域网 中 的 各 个 RabbitMQ 服务 器 来 生产 和 消费 消息 。 联 邦 队 列 
(federated queue) 也 是 通过 单 向 点 对 点 连接 进行 通信 的 ， 消 息 可 以 根据 具体 的 配置 消费 者 的 状 
态 在 联邦 队列 中 游离 任意 次 数 。 


通过 Shovel 来 连接 各 个 RabbitMQ Broker， 概 念 上 与 Federation 的 情形 类 似 ， 不 过 Shovel 
工作 在 更 低 一 层 。 鉴 于 Federation 从 一 个 交换 器 中 转发 消息 到 另 一 个 交换 器 〈 如 果 必 要 可 以 确 
认 消 息 是 否 被 转发 )，Shovel 只 是 简单 地 从 某 个 Broker 上 的 队列 中 消费 消息 ， 然 后 转发 消息 到 
另 一 个 Broker 上 的 交换 器 而 已 。Shovel 也 可 以 在 单独 的 一 台 服 务 器 上 去 转发 消息 ， 比 如 将 一 个 
队列 中 的 数据 移动 到 另 一 个 队列 中 。 如 果 想 获得 比 Federation 更 多 的 控制 ， 可 以 在 广域网 中 使 
用 Shovel 连接 各 个 RabbitMQ Broker 来 生产 或 消费 消息 。 
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通过 以 上 分 析 ， 会 发 现 这 三 种 方式 间 有 着 一 定 的 区 别 和 联系 ， 具 体 请 看 表 8-1. 
表 8-1 Federation/Shovel 与 集群 的 区 别 和 联系 


各 个 Broker 节点 之 间 逻 辑 分 离 逻辑 上 是 一 个 Broker 节点 


个 必须 运行 相 后 
AA Broke WAZ ITUR RAREN Erang 和 RabbiiMG | 阁 个 Btqker 节点 之 间 几 须 运行 相同 版 本 的 Erang 和 
RabbitMQ 
各 个 Broker 节点 之 间 必 须 在 可 信赖 的 局 域 网 中 相连 ， 通 
各 个 Broker 节点 之 间 可 以 在 广域网 中 相连 , 当然 必须 要 授予 适 | 1 
ael euet 过 Erlang 内 部 节点 传递 消息 ， 但 节点 问 需 要 有 相同 的 
Erlang cookie 


各 个 Broker 节点 之 间 能 以 任何 拓扑 逻辑 部 署 , 连接 可 以 是 单 向 
的 或 者 是 双向 的 所 有 Broker 节点 都 双向 连接 所 有 其 他 节点 


从 CAP 理论 中 选择 可 用 性 和 分 区 耐 受 性 ， 即 AP 从 CAP 理论 中 选择 一 致 性 和 可 用 性 ，CA 


— Z 
一 个 Broker 中 的 交换 器 可 以 是 Federation 生成 的 或 者 是 本 地 的 niii aini a RR 八仙 要 全 
: : 
客户 端 所 能 看 到 它 所 连接 的 Broker 节点 上 的 队列 Mz 2 Hes MAEA A 
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到 目前 为 止 ， RTT RabbitMQ 客户 端的 使 用 、 服 务 端的 管理 及 运 维 操控 ， 也 可 谓 是 
RabbitMQ 实战 小 能 手 了 ， 不 过 我 们 还 没有 从 原理 层面 来 进一步 剖析 。 了 解 一 些 RabbitMQ 的 实 
现 原理 也 是 很 有 必要 的 ， 它 可 以 让 你 在 遇 到 问题 时 能 透 过 现象 看 本 质 。 比 如 一 个 队列 的 内 部 存 
储 其 实 是 由 5 个 子 队 列 来 流转 运作 的 ， 队 列 中 的 消息 可 以 有 4 种 不 同 的 状态 等 ， 通 过 这 些 可 以 
明白 在 使 用 RabbitMQ 时 尽量 不 要 有 过 多 的 消息 堆积 ， 不 然 会 影响 整体 服务 的 性 能 。 
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9.1 存储 机 制 


不 管 是 持久 化 的 消息 还 是 非 持 久 化 的 消息 都 可 以 被 写 入 到 磁盘 。 持 久 化 的 消息 在 到 达 队 列 
时 就 被 写 入 到 磁盘 ， 并 且 如 果 可 以 ， 持 久 化 的 消息 也 会 在 内 存 中 保存 一 份 备份 ， 这 样 可 以 提高 
一 定 的 性 能 ， 当 内 存 吃 紧 的 时 候 会 从 内 存 中 清除 。 非 持久 化 的 消息 一 般 只 保存 在 内 存 中， 在 内 
存 吃紧 的 时 候 会 被 换 入 到 磁盘 中 ， 以 节省 内 存 空间 。 这 两 种 类 型 的 消息 的 落 盘 处 理 都 在 
RabbitMQ 的 “持久 层 ” 中 完成 。 


持久 层 是 一 个 逻辑 上 的 概念 ， 实 际 包 含 两 个 部 分 : 队列 索引 〈rabbit_queue_index) 和 
消息 存储 (rabbit msg store). rabbit queue index 负责 维护 队列 中 落 盘 消息 的 信息 , 包 
括 消息 的 存储 地 点 、 是 否 已 被 交付 给 消费 者 、 是 否 已 被 消费 者 ack 等 。 每 个 队列 都 有 与 之 对 应 的 一 
个 rabbit queue index.rabbit msg store 以 键 值 对 的 形式 存储 消息 , 它 被 所 有 队列 共享 ， 
在 每 个 节点 中 有 且 只 有 一 个 。 从 技术 层面 上 来 说 ， rabbit msg store 具体 还 可 以 分 为 
msg_store persistent 和 msg store transient, msg_store persistent 负责 持久 
化 消息 的 持久 化 ， 重 启 后 消息 不 会 丢失 ; msg_store transient 负责 非 持久 化 消息 的 持久 化 ， 
重启 后 消息 会 丢失 。 通 常情 况 下 ， 习 惯性 地 将 msg store persistent 和 msg store 
transient 看 成 rabbit msg store 这 样 一 个 整体 。 


消息 (包括 消息 体 、 属 性 和 headers) 可 以 直接 存储 在 rabbit queue index 中 ,也 可 以 
被 保存 在 rabbit msg store 中 。 默 认 在 $SRABBITMO HOME/var/lib/mnesia/rabbit@ 
$HOSTNAME/ 路 径 下 包含 queues、msg_store_persistent、msg_store_transient 这 3 个 文件 夹 (下面 
信息 中 加 粗 的 部 分 )， 其 分 别 存储 对 应 的 信息 。 


[root@nodel rabbit@nodel]# pwd 
/opt/rabbitmq/var/lib/rabbitmq/mnesia/rabbit@nodel 

[root@nodel rabbit@nodel]# 11 

root root 33 Sep 7 20:03 cluster nodes.config 
root root 155 Sep 10 10:51 DECISION TAB.LOG 
pp proe root root 91 Sep 10 10:51  LATEST.LOG 


-TW = I 
1 
1 
drwxr-xr-x 2 root root 4096 Sep 7 20:03 msg store persistent 
多 
1 
6 


erw-r--r-- 


drwxr-xr-x root root 4096 Sep 7 20:03 msg store transient 
root root 16 Sep 7 20:03 nodes running at shutdown 
root root 4096 Sep 10 11:12 queues 


-rw-r--r-- 
drwxr-xr-x 
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-rw-r--r-- 1l root root 2301 Sep 10 10:51 rabbit durable exchange.DCD 
-EWw-r--f2-- 1 root root 917 Sep 9 23:48 rabbit durable queue.DCD 
erwereer-- l- soot root 1705 Sep 10 10:51 rabbit durable queue.DCL 
-rw-r--r-- 1 root root 1117 Sep 10 10:51 rabbit durable route.DCD 
-rw-r--r-- 1 root root 153 Sep 10 10:51 rabbit runtime parameters.DCD 
—fwW-r--r-- 1 root root 4 Sep 7. 20:03 rabbit serial 

-rw-r--r-- 1 root root 354 Sep 6 18:52 rabbit user.DCD 

-rw-r--r-- l root root 483 Sep 6 18:48 rabbit user permission.DCD 
-rw-r--r-- 1 root root 169 Sep 6 18:37 rabbit vhost.DCD 
-fW-r--r--.1. root foot 5464 Sep 7 20:03 recovery.dets 

-rw-r--r-- 1 root root 21205 Sep 6 18:32 schema.DAT 

-rw-r-er-- 1 root root 285 Sep 6 18:31 schema version 


最 佳 的 配备 是 较 小 的 消息 存储 在 rabbit queue index 中 而 较 大 的 消息 存储 在 
rabbit msg store 中 。 这 个 消息 大 小 的 界定 可 以 通过 queue index embed msgs below 
来 配置 ， 默 认 大 小 为 4096， 单 位 为 B。 注 意 这 里 的 消息 大 小 是 指 消息 体 、 属 性 及 headers 整体 的 
大 小 。 当 一 个 消息 小 于 设 定 的 大 小 病 值 时 就 可 以 存储 在 rabbit queue index 中 ， 这 样 可 以 得 
到 性 能 上 的 优化 。 


rabbit queue index 中 以 顺序 (文件 名 从 0 开始 累加 〉 的 段 文 件 来 进行 存储 ， 后 缀 为 
“.idx ”， 每 个 段 文件 中 包含 固定 的 SEGMENT ENTRY COUNT 条 记录 ， 
SEGMENT ENTRY COUNT 默认 值 为 16384。 每 个 rabbit queue index 从 磁盘 中 读 取 消息 
的 时 候 至 少 要 在 内 存 中 维护 一 个 段 文件 , 所 以 设置 queue index embed msgs below 值 的 
时 候 要 格外 谨慎 ， 一 点 点 增 大 也 可 能 会 引起 内 存 爆炸 式 的 增长 。 


经 过 rabbit msg store 处 理 的 所 有 消息 都 会 以 追加 的 方式 写 入 到 文件 中 ， 当 一 个 文件 
的 大 小 超过 指定 的 限制 (file size limit) 后 ， 关 闭 这 个 文件 再 创建 一 个 新 的 文件 以 供 新 
的 消息 写 入 。 文 件 名 文件 后 级 是“.rdq”) 从 0 开始 进行 累加 ， 因 此 文件 名 最 小 的 文件 也 是 
最 老 的 文件 。 在 进行 消息 的 存储 时 ，RabbitMQ 会 在 ETS (Erlang Term Storage) 表 中 记录 消息 
在 文件 中 的 位 置 映射 “Index) 和 文件 的 相关 信息 (FileSummary ) 。 


在 读 取 消息 的 时 候 ， 先 根据 消息 的 ID (msg id) 找到 对 应 存储 的 文件 ， 如 果 文 件 存在 并 
且 未 被 锁 住 ， 则 直接 打开 文件 ， 从 指定 位 置 读 取消 息 的 内 容 。 如 果 文 件 不 存在 或 者 被 锁 住 了 ， 
则 发 送 请 求 由 rabbit msg store 进行 处 理 。 

消息 的 删除 只 是 从 ETS 表 删 除 指定 消息 的 相关 信息 ,同时 更 新 消息 对 应 的 存储 文件 的 相关 
信息 。 执 行 消息 删除 操作 时 ， 并 不 立即 对 在 文件 中 的 消息 进行 删除 ， 也 就 是 说 消息 依然 在 文件 
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中 ， 仅 仅 是 标记 为 垃圾 数据 而 已 。 当 一 个 文件 中 都 是 垃圾 数据 时 可 以 将 这 个 文件 删除 。 当 检测 
到 前 后 两 个 文件 中 的 有 效 数 据 可 以 合并 在 一 个 文件 中 ， 并 且 所 有 的 垃圾 数据 的 大 小 和 所 有 文件 
CEDE 3 个 文件 存在 的 情况 下 ) 的 数据 大 小 的 比值 超过 设置 的 闷 值 GARBAGE FRACTION (BÀ 
认 值 为 0.5) 时 才 会 触发 垃圾 回收 将 两 个 文件 合并 。 


执行 合并 的 两 个 文件 一 定 是 逻辑 上 相 邻 的 两 个 文件 。 如 图 9-1 所 示 ， 执 行 合并 时 首先 锁定 
这 两 个 文件 ， 并 先 对 前 面 文件 中 的 有 效 数 据 进行 整理 ， 再 将 后 面 文件 的 有 效 数 据 写 入 到 前 面 的 
文件 ， 同 时 更 新 消息 在 ETS 表 中 的 记录 ， 最 后 删除 后 面 的 文件 。 


els pape n 
Q 


Back Front 
图 9-1 垃圾 回收 


9.1.1 队列 的 结构 


通常 队列 由 rabbit amqqueue process 和 backing queue 这 两 部 分 组 成 ， 
rabbit amqqueue process 负责 协议 相关 的 消息 处 理 ， 即 接收 生产 者 发 布 的 消息 、 向 消费 
者 交付 消息 、 处 理 消息 的 确认 包括 生产 端的 confirm 和 消费 端的 ack) 等 。backing queue 
是 消息 存储 的 具体 形式 和 引擎 ,并 向 rabbit amqqueue process 提供 相关 的 接口 以 供 调 用 。 
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如 果 消 息 投递 的 目的 队列 是 空 的 ， 并 且 有 消费 者 订阅 了 这 个 队列 ， 那 么 该 消息 会 直接 发 送 
给 消费 者 ， 不 会 经 过 队列 这 一 步 。 而 当 消 息 无 法 直接 投递 给 消费 者 时 ， 需 要 暂时 将 消息 存 入 队 
列 ， 以 便 重 新 投递 。 消 息 存 入 队列 后 ， 不 是 固定 不 变 的 ， 它 会 随 着 系统 的 负载 在 队列 中 不 断 地 
流动 ， 消 息 的 状态 会 不 断 发 生变 化 。RabbitMQ 中 的 队列 消息 可 能 会 处 于 以 下 4 种 状态 。 


+ alpha: 消息 内 容 〈 包 括 消息 体 、 属 性 和 headers) 和 消息 索引 都 存储 在 内 存 中 。 
信 beta: 消息 内 容 保存 在 磁盘 中 ， 消 息 索引 保存 在 内 存 中 。 

9 gamma: 消息 内 容 保存 在 磁盘 中 ， 消 息 索 引 在 磁盘 和 内 存 中 都 有 。 

* delta: 消息 内 容 和 索引 都 在 磁盘 中 。 


对 于 持久 化 的 消息 ， 消 息 内 容 和 消息 索引 都 必须 先 保存 在 磁盘 上 ， 才 会 处 于 上 述 状态 中 的 
一 种 。 而 gamma 状态 的 消息 是 只 有 持久 化 的 消息 才 会 有 的 状态 。 


RabbitMQ 在 运行 时 会 根据 统计 的 消息 传送 速度 定期 计算 一 个 当前 内 存 中 能 够 保存 的 最 大 
消息 数量 (target_ram count), WR alpha 状态 的 消息 数量 大 于 此 值 时 ， 就 会 引起 消息 的 
状态 转换 ， 多 余 的 消息 可 能 会 转换 到 beta 状态 、gamma 状态 或 者 delta 状态 。 区 分 这 4 种 
状态 的 主要 作用 是 满足 不 同 的 内 存 和 CPU 需求 .alpha 状态 最 耗 内 存 , 但 很 少 消耗 CPU。delta 
状态 基本 不 消耗 内 存 ， 但 是 需要 消耗 更 多 的 CPU 和 磁盘 IO HE. delta 状态 需要 执行 两 次 
LO 操作 才能 读 取 到 消息 ,一 次 是 读 消息 索引 (从 rabbit queue index 中 )， 一 次 是 读 消息 
WA (从 rabbit msg store 中 ); beta 和 gamma 状态 都 只 需要 一 次 IO 操作 就 可 以 读 取 到 
消息 (从 rabbit msg store 中 )。 


对 于 普通 的 没有 设置 优先 级 和 镜像 的 队列 来 说 ，backing_queue 的 默认 实现 是 
rabbit variable queue， 其 内 部 通过 5 个 子 队列 QI Q2, Delta, Q3 和 Q4 来 体现 消息 
的 各 个 状态 。 整 个 队列 包括 rabbit amqqueue process 和 backing_queue 的 各 个 子 队列 ， 
队列 的 结构 可 以 参考 图 9-2。 其 中 QI. Q4 RER alpha 状态 的 消息 ，Q2 和 Q3 包含 peta 和 
gamma 状态 的 消息 ，Delta 只 包含 delta 状态 的 消息 。 一 般 情况 下 ， 消 息 按照 Q1 一 Q2 一 Delta 
-—Q3-Q4 这 样 的 顺序 步骤 进行 流动 ， 但 并 不 是 每 一 条 消息 都 一 定 会 经 历 所 有 的 状态 ， 这 个 取 
决 于 当前 系统 的 负载 状况 .从 Q1 至 Q4 基 本 经 历 内 存 到 磁盘 , 再 由 磁盘 到 内 存 这 样 的 一 个 过 程 ， 
如 此 可 以 在 队列 负载 很 高 的 情况 下 ， 能 够 通过 将 一 部 分 消息 由 磁盘 保存 来 节省 内 存 空间 ， 而 在 
负载 降低 的 时 候 ， 这 部 分 消息 又 渐渐 回 到 内 存 被 消费 者 获取 ， 使 得 整个 队列 具有 很 好 的 弹性 。 
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图 9-2 ”队列 结构 


消费 者 获取 消息 也 会 引起 消息 的 状态 转换 。 当 消费 者 获取 消息 时 ， 首 先 会 从 Q4 中 获取 消 
息 ， 如 果 获 取 成 功 则 返回 。 如 果 Q4 为 空 ， 则 尝试 从 Q3 中 获取 消息 ， 系 统 首 先 会 判断 Q3 是 否 
为 空 , 如 果 为 空 则 返回 队列 为 空 , 即 此 时 队列 中 无 消息 。 如 果 Q3 不 为 空 , 则 取出 Q3 中 的 消息 ， 
进而 再 判断 此 时 Q3 和 Delta 中 的 长 度 ， 如 果 都 为 空 ， 则 可 以 认为 Q2、Delta、Q3、Q4 全 部 为 
空 ， 此 时 将 QI 中 的 消息 直接 转移 至 Q4， 下 次 直接 从 Q4 中 获取 消息 。 如 果 Q3 为 空 ，Delta 不 
为 空 ， 则 将 Delta 的 消息 转移 至 Q3 中 ， 下 次 可 以 直接 从 Q3 中 获取 消息 。 在 将 消息 从 Delta ££ 
移 到 Q3 的 过 程 中 ， 是 按照 索引 分 段 读 取 的 ， 首 先 读 取 某 一 段 ， 然 后 判断 读 取 的 消息 的 个 数 与 
Delta 中 消息 的 个 数 是 否 相 等 ， 如 果 相 等 ， 则 可 以 判定 此 时 Delta 中 已 无 消息 ， 则 直接 将 Q2 和 
刚 读 取 到 的 消息 一 并 放 入 到 Q3 中 ; 如 果 不 相等 ， 仅 将 此 次 读 取 到 的 消息 转移 到 Q3。 


这 里 就 有 两 处 疑问 , 第 一 个 疑问 是 : 为 什么 Q3 为 空 则 可 以 认定 整个 队列 为 空 ”试想 一 下 ， 
如 果 Q3 为 空 ，Delta 不 为 空 ， 那 么 在 Q3 取出 最 后 一 条 消息 的 时 候 ，Delta 上 的 消息 就 会 被 转移 
到 Q3， 这 样 与 Q3 为 空 矛盾 ;如果 Delta 为 空 且 Q2 不 为 空 ， 则 在 Q3 取出 最 后 一 条 消息 时 会 将 
Q2 的 消息 并 入 到 Q3 中 ,这 样 也 与 Q3 为 空 矛盾 ;在 Q3 取出 最 后 一 条 消息 之 后 ,如 果 Q2、Delta、 
Q3 3517975, HQ 不 为 空 时 ， 则 QI 的 消息 会 被 转移 到 Q4， 这 与 QA 为 空 矛 盾 。 其 实 这 一 番 论 
述 也 解释 了 另 一 个 问题 ， 为 什么 Q3 和 Delta 都 为 空 时 ， 则 可 以 认为 Q2、Delta、Q3、Q4 全 部 
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为 空 ? 

通常 在 负载 正常 时 ， 如 果 消 息 被 消费 的 速度 不 小 于 接收 新 消息 的 速度 ， 对 于 不 需要 保证 可 
靠 不 丢 失 的 消息 来 说 , 极 有 可 能 只 会 处 于 alpha 状态 .对 于 durable 属性 设置 为 true 的 消息 ， 
它 一 定 会 进入 gamma 状态 ， 并 且 在 开启 publisher confirm 机 制 时 ， 只 有 到 了 gamma 状态 时 才 
会 确认 该 消息 已 被 接收 ， 若 消息 消费 速度 足够 快 、 内 存 也 充足 ， 这 些 消息 也 不 会 继续 走 到 下 一 
个 状态 。 

在 系统 负载 较 高 时 ， 已 接收 到 的 消息 若 不 能 很 快 被 消费 掉 ， 这 些 消 息 就 会 进入 到 很 深 的 队 
列 中 去 ， 这 样 会 增加 处 理 每 个 消息 的 平均 开销 。 因 为 要 花 更 多 的 时 间 和 资源 处 理 “ 堆 积 ” 的 消 
息 ， 如 此 用 来 处 理 新 流入 的 消息 的 能 力 就 会 降低 ， 使 得 后 流入 的 消息 又 被 积压 到 很 深 的 队列 中 
继续 增 大 处 理 每 个 消息 的 平均 开销 , 继而 情况 变 得 越 来 越 恶 化 , 使 得 系统 的 处 理 能 力 大 大 降低 。 

应 对 这 一 问题 一 般 有 3 种 措施 : 

(1) 增加 prefetch_count 的 值 ， 即 一 次 发 送 多 条 消息 给 消费 者 ， 加 快 消息 被 消费 的 速度 ， 详 
细 用 法 可 以 参考 4.9.1 节 ; 

(2) 采用 multiple ack， 降 低 处 理 ack 带 来 的 开销 ， 详 细 用 法 可 以 参考 3.5 节 ; 

(3) 流量 控制 ， 详 细 内 容 可 以 参考 9.3 节 。 


9.1.2 ”惰性 队列 





RabbitMQ 从 3.6.0 版 本 开始 引入 了 惰性 队列 (Lazy Queue). 的 概念 。 惰 性 队列 会 尽 可 能 地 
将 消息 存 入 磁盘 中 ， 而 在 消费 者 消费 到 相应 的 消息 时 才 会 被 加 载 到 内 存 中 ， 它 的 一 个 重要 的 设 
计 目 标 是 能 够 支持 更 长 的 队列 ， 即 支持 更 多 的 消息 存储 。 当 消费 者 由 于 各 种 各 样 的 原因 (比如 
消费 者 下 线 、 宕 机 ， 或 者 由 于 维护 而 关闭 等 ) 致使 长 时 间 内 不 能 消费 消息 而 造成 堆积 时 ， 惰 性 
队列 就 很 有 必要 了 。 


默认 情况 下 ， 当 生产 者 将 消息 发 送 到 RabbitMQ 的 时 候 ， 队 列 中 的 消息 会 尽 可 能 地 存储 在 
内 存 之 中 ， 这 样 可 以 更 加 快速 地 将 消息 发 送 给 消费 者 。 即 使 是 持久 化 的 消息 ， 在 被 写 入 磁盘 的 
同时 也 会 在 内 存 中 驻 留 一 份 备 份 。 当 RabbitMQ 需要 释放 内 存 的 时 候 ， 会 将 内 存 中 的 消息 换 页 
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至 磁盘 中 ， 这 个 操作 会 耗费 较 长 的 时 间 ， 也 会 阻塞 队列 的 操作 ， 进 而 无 法 接收 新 的 消息 。 虽 然 
RabbitMQ 的 开发 者 们 一 直 在 升级 相关 的 算法 , 但 是 效果 始终 不 太 理想 , 尤其 是 在 消息 量 特别 大 
的 时 候 。 


惰性 队列 会 将 接收 到 的 消息 直接 存 入 文件 系统 中 ， 而 不 管 是 持久 化 的 或 者 是 非 持 久 化 的 ， 
这 样 可 以 减少 了 内 存 的 消耗 ， 但 是 会 增加 IO 的 使 用 ， 如 果 消 息 是 持久 化 的 ， 那 么 这 样 的 UO 
操作 不 可 避免 ， 惰 性 队列 和 持久 化 的 消息 可 谓 是 “最 佳 拍档 ”。 注意 如 果 惰 性 队列 中 存储 的 是 非 
持久 化 的 消息 ， 内 存 的 使 用 率 会 一 直 很 稳定 ， 但 是 重启 之 后 消息 一 样 会 丢失 。 


队列 具备 两 种 模式 : default 和 1lazy。 默 认 的 为 default 模式 , 在 3.6.0 之 前 的 版 本 无 
须 做 任何 变更 。1azy 模式 即 为 惰性 队列 的 模式 ， 可 以 通过 调用 channel.queueDeclare 7j 
法 的 时 候 在 参数 中 设置 ， 也 可 以 通过 Policy 的 方式 设置 ， 如 果 一 个 队列 同时 使 用 这 两 种 方式 设 
置 ， 那 么 Policy 的 方式 具备 更 高 的 优先 级 。 如 果 要 通过 声明 的 方式 改变 已 有 队列 的 模式 ， 那 么 
只 能 先 删除 队列 ， 然 后 再 重新 声明 一 个 新 的 。 


在 队列 声明 的 时 候 可 以 通过 x -queue-mode 参数 来 设置 队列 的 模式 , 取 值 为 default 和 
lazy。 下 面 示例 演示 了 一 个 惰性 队列 的 声明 细节 :; 2 


Map<String, Object» args = new HashMap«String, Object»(); 


args.put("x-queue-mode", "lazy"); 

channel.queueDeclare("myqueue", false, false, false, args); 

对 应 的 Policy 设置 方式 为 : 

rabbitmqctl set policy Lazy "^myqueue$" '("queue-mode":"lazy"]' --apply-to 
queues 


惰性 队列 和 普通 队列 相 比 ， 只 有 很 小 的 内 存 开销 。 这 里 很 难 对 每 种 情况 给 出 一 个 具体 的 数 
值 ， 但 是 我 们 可 以 类 比 一 下 : 发 送 1 千 万 条 消息 ， 每 条 消息 的 大 小 为 IKB， 并 且 此 时 没有 任何 
的 消费 者 ， 那 么 普通 队列 会 消耗 1.2GB 的 内 存 ， 而 惰性 队列 只 消耗 1.5MB 的 内 存 。 


据 官方 测试 数据 显示 ， 对 于 普通 队列 ， 如 果 要 发 送 1 千 万 条 消息 ， 需 要 耗费 801 秒 ， 平 均 
发 送 速度 约 为 13000 条 / 秒 。 如 果 使 用 惰性 队列 ， 那 么 发 送 同样 多 的 消息 时 ， 耗 时 是 421 秒 ， 平 
均 发 送 速度 约 为 24000 条 / 秒 。 出 现 性 能 偏差 的 原因 是 普通 队列 会 由 于 内 存 不 足 而 不 得 不 将 消息 
换 页 至 磁盘 。 如 果 有 消费 者 消费 时 ， 惰 性 队列 会 耗费 将 近 40MB 的 空间 来 发 送 消息 ， 对 于 一 个 
消费 者 的 情况 ， 平 均 的 消费 速度 约 为 14000 条 / 秒 。 
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如 果 要 将 普通 队列 转变 为 惰性 队列 ， 那 么 我 们 需要 忍受 同样 的 性 能 损耗 ， 首 先 需要 将 缓存 
中 的 消息 换 页 至 磁盘 中 ， 然 后 才能 接收 新 的 消息 。 反 之 ， 当 将 一 个 惰性 队列 转变 为 普通 队列 的 
时 候 ， 和 恢复 一 个 队列 执行 同样 的 操作 ， 会 将 磁盘 中 的 消息 批量 地 导入 到 内 存 中 。 


92 ”内 存 及 磁盘 告警 


当 内 存 使 用 超过 配置 的 阐 值 或 者 磁盘 剩余 空间 低 于 配置 的 阔 值 时 ，RabbitMQ 都 会 暂时 阻塞 
(block) 客户 端的 连接 (Connection) 并 停止 接收 从 客户 端 发 来 的 消息 ， 以 此 避免 服务 崩 演 。 与 此 同 
时 ， 客 户 端 与 服务 端的 心跳 检测 也 会 失效 。 可 以 通过 rabbitmqctl list connections 命令 
或 者 Web 管理 界面 来 查看 它 的 状态 ， 如 图 9-3 所 示 。 


Details 
User name State SSL/TLS Protocol Channels 
root blocking — s AMQPO0-9-1 1 
rot (M blocked |  。 |AMQp0-91| 1 


图 9-3 Connection 的 状态 


被 阻塞 的 Connection 的 状态 要 么 是 blocking， 要 么 是 blocked。 前 者 对 应 于 并 不 试图 
发 送 消息 的 Connection， 比 如 消费 者 关联 的 Connection， 这 种 状态 下 的 Connection 可 以 继续 运 
行 。 而 后 者 对 应 于 一 直 有 消息 发 送 的 Connection, 这 种 状态 下 的 Connection 会 被 停止 发 送 消息 。 
注意 在 一 个 集群 中 ， 如 果 一 个 Broker 节点 的 内 存 或 者 磁盘 受 限 ， 都 会 引起 整个 集群 中 所 有 的 
Connection 被 阻塞 。 


理想 的 情况 是 当 发 生 阻塞 时 可 以 在 阻止 生产 者 的 同时 而 又 不 影响 消费 者 的 运行 。 但 是 在 
AMQP 协议 中 ， 一 个 信道 CChannel) 上 可 以 同时 承载 生产 者 和 消费 者 ， 同 一 个 Connection 中 也 
可 以 同时 承载 若干 个 生产 者 的 信道 和 消费 者 的 信道 ， 这 样 就 会 使 阻塞 罗 辑 错乱 ， 虽 然 大 多 数 情 
况 下 并 不 会 发 生 任何 问题 ， 但 还 是 建议 生产 和 消费 的 逻辑 可 以 分 摊 到 独立 的 Connection 之 上 而 
不 发 生 任何 交集 。 客 户 端 程序 可 以 通过 添加 BlockedListener 来 监听 相应 连接 的 阻塞 信息 ， 
示例 可 以 参考 代码 清单 7-11。 
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9.2.1 内 存 告警 


RabbitMQ 服务 器 会 在 启动 或 者 执行 rabbitmqctl set vm memory high watermark 
fraction 命令 时 计算 系统 内 存 的 大 小 默认 情况 下 vm_memory_high_watermark 的 值 为 0.4， 
即 内 存 阔 值 为 0.4， 表 示 当 RabbitMQ 使 用 的 内 存 超过 40% 时 ， 就 会 产生 内 存 告 警 并 阻塞 所 有 生产 
者 的 连接 。 一 旦 告警 被 解除 《有 消息 被 消费 或 者 从 内 存 转 储 到 磁盘 等 情况 的 发 生 )， 一 切 都 会 恢复 
正常 。 

默认 情况 下 将 RabbitMQ 所 使 用 内 存 的 阔 值 设置 为 40%， 这 并 不 意味 着 此 时 RabbitMQ 不 
能 使 用 超过 40% 的 内 存 ， 这 仅仅 只 是 限制 了 RabbitMQ 的 消息 生产 者 。 在 最 坏 的 情况 下 ，Erlang 
的 垃圾 回收 机 制 会 导致 两 倍 的 内 存 消耗 ， 也 就 是 80% 的 使 用 占 比 。 

内 存 浆 值 可 以 通过 rabbitmq.config 配置 文件 来 配置 , 下 面 示例 中 设置 了 默认 的 内 存 立 
值 为 0.4: 

[ 


rabbit, [ 
(vm memory high watermark, 0.4) 


] 
l. 
与 此 配置 对 应 的 rabbitmqctl 系列 的 命令 为 : 
rabbitmqctl set vm memory high watermark {fraction} 
fraction 对 应 上 面 配置 中 的 0.4， 表 示 占 用 内 存 的 百分比 ， 取 值 为 大 于 等 于 0 的 浮 点 数 。 
设置 对 应 的 百分比 值 之 后 ,RabbitMQ 中 会 打印 服务 日 志 。 当 在 内 存 为 7872MB 的 节点 中 设置 内 
TERRI 0.4 时 ， 会 有 如 下 信息 : 


-INFO REPORT---- 4-Sep-2017::20:30:09 === 
Memory limit set to 3148MB of 7872MB total. 


此 时 又 将 fraction 设置 为 0.1, 同时 发 出 了 内 存 告警 , 相应 的 服务 日 志 会 打印 如 下 信息 : 


-INFO REPORT==== 4-Sep-2017::20:29:55 === 
Memory limit set to 787MB of 7872MB total. 


-INFO REPORT---- 4-$8ep-2017::20:29:55 === 
vm memory high watermark set. Memory used:1163673112 allowed:825482444 
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=WARNING REPORT==== 4-Sep-2017::20:29:55 === 
memory resource limit alarm set on node rabbit@nodel. 


e e e e oe e oe oe oe e eoe oe oe oe oe oe oe oe oe ke oe oe oe oe oe ke oe oe oe oe oe oe oe oe oe oe ke oe oe oe oe oe cede ke ke ck oe e ek € x | x x 


*** Publishers will be blocked until this alarm clears *** 
e e e e oe oe oe oe e he ode obe oe oe oe oe he ode ode oe oe oe oe oe oe oe oe oe oe oe oe ke oe oe oe oe oe oe coke oe oe oe oe coke oe oe ke ke coe ok oe ke ok coke oe kk ox 


之 后 又 设置 fraction 为 0.4 以 消除 内 存 告 警 ， 相 应 的 服务 日 志 会 打印 如 下 信息 : 
-INFO REPORT==== 4-Sep-2017::20:30:01 === 
vm memory high watermark clear. Memory used:693482232 allowed:825482444 


-WARNING REPORT--2-- 4-Sep-2017::20:30:01 === 
memory resource limit alarm cleared on node rabbitG8nodel 


-WARNING REPORT---- 4-Sep-2017::20:30:01 === 
memory resource limit alarm cleared across the cluster 


如 果 设 置 fraction 为 0， 所 有 的 生产 者 都 会 被 停止 发 送 消息 。 这 个 功能 可 以 适用 于 需要 
禁止 集群 中 所 有 消息 发 布 的 情况 。 正 常情 况 下 建议 vm memory high watermark 取 值 在 0.4 
到 0.66 之 间 ， 不 建议 取 值 超过 0.7。 


假设 机 器 的 内 存 为 4GB， 那 么 就 代表 RabbitMQ 服务 的 内 存 阔 值 的 绝对 值 为 
4GBx0.4=1.6GB。 如 果 是 32 位 的 Windows 操作 系统 ， 那 么 可 用 内 存 被 限制 为 2GB， 也 就 意味 
着 RabbitMQ 服务 的 内 存 阔 值 的 绝对 值 为 820MB 左右 。 除 了 通过 百分比 的 形式 ，RabbitMQ 也 
可 以 采用 绝对 值 的 形式 来 设置 内 存 阀 值 ， 默 认 单位 为 B。 下 面 示例 设置 了 内 存 阔 值 的 绝对 值 为 
1024MB (1024x 1024x 1024B-1073741824B): 

[ 


rabbit, [ 
(vm memory high watermark, (absolute, 1073741824]] 
] 


ji 
纯 数字 的 配置 可 读 性 较 差 ，RabbitMQ 中 也 提供 了 单位 的 形式 ， 对 应 的 示例 如 下 : 


[{rabbit, [{vm memory high watermark, {absolute, "1024MiB"}}]}]. 

可 用 的 内 存单 位 有 : K 或 KiB 表示 千 字 节 ， 大 小 为 2*B; M 或 MiB 表示 兆 字 节 ， 大 小 为 
2"B; G 或 GIB 表示 千 兆 字 节 ， 大 小 为 22B。 注 意 这 里 的 内 存单 位 还 可 以 设置 为 : KB， 大 小 为 
10; MB, X/ 106; GB, K/h» 109. 
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与 绝对 值 配置 对 应 的 rabbitmqctl 系列 的 命令 为 : 


rabbitmqctl set vm memory high watermark absolute (memory limit) 





不 管 是 这 个 命令 还 是 rabbitmqct1l set vm memory high watermark (fraction) 
命令 ， 在 服务 器 重启 之 后 所 设置 的 阐 值 都 会 失效 ， 而 通过 配置 文件 的 方式 设置 的 阐 值 则 不 会 在 
重启 之 后 失效 ， 但 是 修改 后 的 配置 需要 在 重启 之 后 才能 生效 。 


在 某 个 Broker 节点 触及 内 存 并 阻塞 生产 者 之 前 , 它 会 尝试 将 队列 中 的 消息 换 页 到 磁盘 以 释 
放 内 存 空 间 。 持 久 化 和 非 持久 化 的 消息 都 会 被 转 储 到 磁盘 中 ， 其 中 持久 化 的 消息 本 身 就 在 磁盘 
中 有 一 份 副本 ， 这 里 会 将 持久 化 的 消息 从 内 存 中 清除 掉 。 


默认 情况 下 ， 在 内 存 到 达 内 存 阔 值 的 50% 时 会 进行 换 页 动作 。 也 就 是 说 ， 在 默认 的 内 存 阐 
值 为 0.4 的 情况 下 ， 当 内 存 超过 0.4x0.5=0.2 时 会 进行 换 页 动作 。 可 以 通过 在 配置 文件 中 配置 
vm memory high watermark paging ratio 项 来 修改 此 值 。 下面 示例 中 将 换 页 比率 从 默 
认 的 0.5 修改 为 0.75: 


[ 
{rabbit, 
[ 
{vm memory high watermark paging ratio, 0.75}, 
{vm memory high watermark, 0.4} 


] 

Jó 

上 面 的 配置 会 在 RabbitMQ 内 存 使 用 率 达到 30% 时 进行 换 页 动作 , 并 在 40% 时 阻塞 生产 者 。 
可 以 将 vm memory high watermark paging ratio 值 设置 为 大 于 1 的 浮 点 数 ， 这 种 配 
置 相当 于 禁用 了 换 页 功能 。 注 意 这 里 RabbitMQ 中 并 没有 类 似 rabbitmqctl vm memory 
high watermark paging ratio {xxx} 的 命令 。 

如 果 RabbitMQ 无 法 识别 所 在 的 操作 系统 ， 那 么 在 启动 的 时 候 会 在 日 志文 件 中 追加 一 些 信 
息 ， 并 将 内 存 的 值 假定 为 1GB。 相 应 的 日 志 信息 参考 如 下 : 


-WARNING REPORT==== 5-Sep-2017::17:23:44 === 
Unknown total memory size for your OS (unix,magic homebrew os]. Assuming memory 
size is 1024MB. 


对 应 vm memory high watermark 为 0.4 的 情形 来 说 ，RabbitMQ f] pfe BELA Jy 
410MB。 如 果 操 作 系统 本 身 的 内 存 大 小 为 8GB， 可 以 将 vm memory high watermark 设置 
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为 3， 这 样 内 存 闵 值 就 提高 到 了 3GB. 


9.22 ”磁盘 告警 


当 剩 余 磁 盘 空 间 低 于 确定 的 阀 值 时 ，RabbitMQ 同样 会 阻塞 生产 者 , 这 样 可 以 避免 因 非 持久 
化 的 消息 持续 换 页 而 耗 尽 磁盘 空间 导致 服务 崩溃 。 默 认 情 况 下 ， 磁 盘 阔 值 为 50MB， 这 意味 着 
当 磁 盘 剩 余 空间 低 于 50MB 时 会 阻塞 生产 者 并 停止 内 存 中 消息 的 换 页 动作 。 这 个 阔 值 的 设置 可 
以 减 小 但 不 能 完全 消除 因 磁 盘 耗 尽 而 导致 崩溃 的 可 能 性 ， 比 如 在 两 次 磁盘 空间 检测 期 间 内 ， 磁 
盘 空 间 从 大 于 50MB 被 耗 尽 到 OMB 一 个 相对 谨慎 的 做 法 是 将 磁盘 阔 值 设置 为 与 操作 系统 所 显 
示 的 内 存 大 小 一 致 。 


在 Broker 节点 启动 的 时 候 会 默认 开启 磁盘 检测 的 进程 ， 相 对 应 的 服务 日 志 为 : 


=INFO REPORT==== 7-Sep-2017::20:03:00 === 
Disk free limit set to 50MB 


对 于 不 识别 的 操作 系统 而 言 ， 磁 盘 检 测 功能 会 失效 ， 对 应 的 服务 日 志 为 : 


-WARNING REPORT---- 7-Sep-2017::15:45:29 --- 
Disabling disk free space monitoring 


RabbitMQ 会 定期 检测 磁盘 剩余 空间 , 检测 的 频率 与 上 一 次 执行 检测 到 的 磁盘 剩余 空间 大 小 
有 关 。 正 常情 况 下 ， 每 10 秒 执行 一 次 检测 ， 随 着 磁盘 剩余 空间 与 磁盘 闵 值 的 接近 ， 检 测 频 率 会 
有 所 增加 。 当 要 到 达 磁 盘 闵 值 时 ， 检 测 频 率 为 每 秒 10 次 ， 这 样 有 可 能 会 增加 系统 的 负载 。 


可 以 通过 在 配置 文件 中 配置 disk_free limit 项 来 设置 磁盘 闵 值 ,下 面 示例 中 将 磁盘 冰 
值 设置 为 1GB 左右 : 


[ 
{ 
rabbit, [ 
(disk free limit, 1000000000) 
] 


]. 


这 里 也 可 以 使 用 单位 设置 ， 单 位 的 选择 可 以 参照 内 存 浆 值 的 设置 (KB，KiB，MB，MiB， 
GB，GiB)。 示 例如 下 : 
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[(rabbit, [(disk free limit, "1GB"]]]]. 


还 可 以 参考 机 器 内 存 的 大 小 为 磁盘 阔 值 设置 一 个 相对 的 比值 。 比 如 将 磁盘 阔 值 设置 为 与 集 
群 内 存 一 样 大 : 


[ 
{ 
rabbit, [ 
(disk free limit, (mem relative, 1.0]) 
] 
} 
] 


与 绝对 值 和 相对 值 这 两 种 配置 对 应 的 rabbitmactl 系列 的 命令 为 : rabbitmdct1l 
set disk free limit (disk limit} 和 rabbitmqctl set disk free limit mem 
relative (fraction), AIATFBEBRJUEE S  H Broker 重启 之 后 将 会 失效 。 同 样 ， 通 
过 配置 文件 的 方式 设置 的 冰 值 则 不 会 在 重启 之 后 失效 ， 但 是 修改 后 的 配置 需要 在 重启 之 后 才能 生 
效 。 正 常情 况 下 ， 建 议 disk free limit. mem relative 的 取 值 为 1.0 和 2.0 之 间 。 


9.3 ifi 


RabbitMQ FJ AX PALECRUE SE ER] REBEL EL, SESB, EARE Clock), 
直到 对 应 项 恢复 正常 。 除 了 这 两 个 阔 值 ,从 2.8.0 版 本 开始 ,RabbitMQ 还 引入 了 流 控 (Flow Control) 
机 制 来 确保 稳定 性 。 流 控 机 制 是 用 来 避免 消息 的 发 送 速率 过 快 而 导致 服务 器 难以 支撑 的 情形 。 
内 存 和 磁盘 告警 相当 于 全 局 的 流 控 (Global Flow Control)， 一 旦 触发 会 阻塞 集群 中 所 有 的 
Connection， 而 本 节 的 流 控 是 针对 单个 Connection 的 ， 可 以 称 之 为 Per-Connection Flow Control 
或 者 Internal Flow Control。 


Erlang 进程 之 间 并 不 共享 内 存 Cbinary 类 型 的 除外 )， 而 是 通过 消息 传递 来 通信 ， 每 个 进程 
都 有 自己 的 进程 邮箱 (mailbox). RUI F, Erlang 并 没有 对 进程 邮箱 的 大 小 进行 限制 ， 所 
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以 当 有 大 量 消息 持续 发 往 某 个 进程 时 ， 会 导致 该 进程 邮箱 过 大 ， 最 终 内 存 滋 出 并 崩溃 。 在 
RabbitMQ 中 ， 如 果 生 产 者 持续 高 速 发 送 ， 而 消费 者 消费 速度 较 低 时 ， 如 果 没 有 流 控 ， 很 快 就 会 
使 内 部 进程 邮箱 的 大 小 达到 内 存 阀 值 。 


RabbitMQ 使 用 了 一 种 基于 信用 证 算法 (credit-based algorithm? 的 流 控 机 制 来 限制 发 送 消息 
的 速率 以 解决 前 面 所 提出 的 问题 。 它 通过 监控 各 个 进程 的 进程 邮箱 ， 当 某 个 进程 负载 过 高 而 来 
不 及 处 理 消 息 时 ， 这 个 进程 的 进程 邮箱 就 会 开始 堆积 消息 。 当 堆积 到 一 定量 时 ， 就 会 阻塞 而 不 
接收 上 游 的 新 消息 。 从 而 慢 慢 地 ， 上 游 进程 的 进程 邮箱 也 会 开始 堆积 消息 。 当 堆积 到 一 定量 时 
也 会 阻塞 而 停止 接收 上 游 的 消息 ， 最 后 就 会 使 负责 网 络 数据 包 接收 的 进程 阻塞 而 暂停 接收 新 的 
数据 。 


就 以 图 9-4 为 例 ， 进 程 A 接收 消息 并 转发 至 进程 B， 进 程 B 接收 消息 并 转发 至 进程 C。 每 
个 进程 中 都 有 一 对 关于 收发 消息 的 credit 值 ,以 进程 B 为 例 , ( (credit from, C), value) 
表示 能 发 送 多 少 条 消息 给 C， 每 发 送 一 条 消息 该 值 减 1， 当 为 0 时， 进程 B 不 再 往 进程 C 发 送 
消息 也 不 再 接收 进程 A 的 消息 。{ {credit to，A}，value} 表 示 再 接收 多 少 条 消息 就 向 进 
FE A 发 送 增加 credit 值 的 通知 , 进程 A 接收 到 该 通知 后 就 增加 { {credit_from, B), value] 
所 对 应 的 值 ， 这 样 进程 A 就 能 持续 发 送 消息 。 当 上 游 发 送 速 率 高 于 下 游 接 收 速率 时 ，credit 
值 就 会 被 逐渐 耗 光 ， 这 时 进程 就 会 被 阻塞 ， 阻 塞 的 情况 会 一 直 传递 到 最 上 游 。 当 上 游 进程 收 到 
来 自 下 游 进程 的 增加 credit 值 的 通知 时 ， 若 此 时 上 游 进程 处 于 阻塞 状态 则 解除 阻塞 ， 开 始 接 
收 更 上 游 进程 的 消息 ， 一 个 一 个 传导 最 终 能 够 解除 最 上 游 的 阻塞 状态 。 由 此 可 知 ， 基 于 信用 证 
的 流 控 机 制 最 终 将 消息 发 送 进程 的 发 送 速率 限制 在 消息 处 理 进 程 的 处 理 能 力 范围 之 内 。 


((credit from. B). value) (credit from, C). value) (credit from. xa}, value) 
((credit ro. ;x}. value? ((credit to. A). value) [^s B). value) 


(=) > (=) > 


9-4 ”信用 证 算法 


一 个 连接 (Connection) 触发 流 控 时 会 处 于 “flow” 的 状态 ， 也 就 意味 着 这 个 Connection 
的 状态 每 秒 在 blocked 和 unblocked 之 间 来 回 切换 数 次 ,这 样 可 以 将 消息 发 送 的 速率 控制 在 
服务 器 能 够 支撑 的 范围 之 内 。 可 以 通过 rabbitmqctl list connections 命令 或 者 Web 
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管理 界面 来 查看 Connection 的 状态 ， 如 图 9-5 所 示 。 


Details 
User name State SSL/TLS Protocol Channels Frame max 
root | flow (| o AMQP 0-9-1! . il 131072. 


9-5 Connection 的 状态 


处 于 flow 状态 的 Connection 和 处 于 running 状态 的 Connection 并 没有 什么 不 同 ， 这 个 
状态 只 是 告诉 系统 管理 员 相 应 的 发 送 速 率 受 限 了 。 而 对 于 客户 端 而 言 ， 它 看 到 的 只 是 服务 器 的 
带宽 要 比 正常 情况 下 要 小 一 些 。 


流 控 机 制 不 只 是 作用 于 Connection， 同 样 作用 于 信道 (Channel) 和 队列 。 从 Connection 到 
Channel， 再 到 队列 ， 最 后 是 消息 持久 化 存储 形成 一 个 完整 的 流 控 链 ， 对 于 处 于 整个 流 控 链 中 的 
任意 进程 ， 只 要 该 进程 阻塞 ， 上 游 的 进程 必定 全 部 被 阻塞 。 也 就 是 说 ， 如 果 某 个 进程 达到 性 能 
瓶颈 ， 必 然 会 导致 上 游 所 有 的 进程 被 阻塞 。 所 以 我 们 可 以 利用 流 控 机 制 的 这 个 特点 找 出 瓶颈 之 
所 在 。 处 理 消 息 的 几 个 关键 进程 及 其 对 应 的 顺序 关系 如 图 9-6 所 示 。 


Der) re) 


图 9-6 流 控 链 
其 中 的 各 个 进程 如 下 所 述 。 
* rabbit reader: Connection 的 处 理 进程 ， 负 责 接收 、 解 析 AMQP 协议 数据 包 等 。 


分 rabbit channel: Channel 的 处 理 进程 ， 负 责 处 理 AMQP 协议 的 各 种 方法 、 进 行路 
由 解析 等 。 


* rabbit amqqueue process: 队列 的 处 理 进程 ， 负 责 实现 队列 的 所 有 逻辑 。 
* rabbit msg store: 负责 实现 消息 的 持久 化 。 


当 某 个 Connection 处 于 flow 状态 ， 但 这 个 Connection 中 没有 一 个 Channel 处 于 flow 状 
态 时 ， 这 就 意味 这 个 Connection 中 有 一 个 或 者 多 个 Channel 出 现 了 性 能 瓶颈 。 某 些 Channel 进 
程 的 运作 (比如 处 理 路 由 逻辑 ) 会 使 得 服务 器 CPU 的 负载 过 高 从 而 导致 了 此 种 情形 。 尤 其 是 在 
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发 送 大 量 较 小 的 非 持久 化 消息 时 ， 此 种 情形 最 易 显 现 。 


当 某 个 Connection 处 于 flow 状态 ,并 且 这 个 Connection 中 也 有 若干 个 Channel 处 于 flow 
状态 ， 但 没有 任何 一 个 对 应 的 队列 处 于 flow 状态 时 ， 这 就 意味 着 有 一 个 或 者 多 个 队列 出 现 了 
性 能 瓶颈 。 这 可 能 是 由 于 将 消息 存 入 队列 的 过 程 中 引起 服务 器 CPU 负载 过 高 ， 或 者 是 将 队列 中 
的 消息 存 入 磁盘 的 过 程 中 引起 服务 器 IO 负载 过 高 而 引起 的 此 种 情形 。 尤 其 是 在 发 送 大 量 较 小 
的 持久 化 消息 时 ， 此 种 情形 最 易 显 现 。 


当 某 个 Connection 处 于 flow 状态 ， 同 时 这 个 Connection 中 也 有 若干 个 Channel 处 于 flow 
状态 ， 并 且 也 有 若干 个 对 应 的 队列 处 于 flow 状态 时 ， 这 就 意味 着 在 消息 持久 化 时 出 现 了 性 能 
瓶颈 。 在 将 队列 中 的 消息 存 入 磁盘 的 过 程 中 引起 服务 器 IO 负载 过 高 而 引起 的 此 种 情形 。 尤 其 
是 在 发 送 大量 较 大 的 持久 化 消息 时 ， 此 种 情形 最 易 显 现 。 


9.3.2 案例: 打破 队列 的 瓶颈 


图 9-6 中 描绘 了 一 条 消息 从 接收 到 存储 的 一 个 必需 的 流 控 连 。 一 般 情况 下 ， 向 一 个 队列 里 
推送 消息 时 ， 往 往 会 在 rabbit amqqueue process 中 ( 即 队列 进程 中 ) 产生 性 能 瓶颈 。 在 
向 一 个 队列 中 快速 发 送 消息 的 时 候 ，Connection 和 Channel 都 会 处 于 flow 状态 ， 而 队列 处 于 
running 状态 ， 这 样 通过 9.3.1 节 末 尾 的 分 析 可 以 得 出 在 队列 进程 中 产生 性 能 瓶颈 的 结论 。 在 
一 台 CPU 主 频 为 2.6Hz、CPU 内 核 为 4、 内 存 为 8GB、 磁 盘 为 40GB 的 虚拟 机 中 测试 向 单个 队 
列 中 发 送 非 持 久 化 、 大 小 为 10B 的 消息 ， 消 息 发 送 的 QPS 平均 为 18k 左右 。 如 果 开 启 publisher 
confirm 机 制 、 持 久 化 消息 及 增 大 payload 都 会 降低 这 个 QPS 的 数值 。 


这 里 就 引入 了 本 节 所 要 解决 的 问题 : 如 何 提升 队列 的 性 能 ?一 般 可 以 有 两 种 解决 方案 : 第 一 种 
是 开启 Erlang 语言 的 HiPE 功能 ， 这 样 保守 估计 可 以 提高 30% 一 40% 的 性 能 ， 不 过 在 较 旧 版 本 的 
Erlang 中 ， 这 个 功能 不 太 稳 定 ， 建 议 使 用 较 新 版 本 的 Erlang， 版 本 至 少 是 18.x。 不 管 怎样 ，HiPE © 
然 不 是 本 节 的 主题 。 第 二 种 是 寻求 打破 rabbit amqqueue process 的 性 能 瓶颈 。 这 里 的 打破 
是 指 以 多 个 rabbit amqqueue process 替换 单个 rabbit amqqueue process， 这 样 可 以 
充分 利用 上 rabbit reader BÉ rabbit channel 进程 中 被 流 控 的 性 能 ， 如 图 9-7 所 示 。 
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rabbit smaqueue 
-process 
CG” 
aie ig 
rabbit smqqueue 
-process 


9-7 利用 多 个 rabbit amqqueue process 替换 单个 rabbit amqqueue process 


这 里 读者 会 有 疑问 ， 这 不 就 变 成 了 多 个 队列 了 吗 ? 的 确 ， 如 果 在 应 用 代码 中 直接 使 用 多 个 
队列 , 则 会 侵入 原 有 代码 的 逻辑 使 其 复杂 化 , 同时 可 读 性 也 差 。 这 里 所 要 做 的 一 件 事 就 是 封装 。 
将 交换 器 、 队 列 、 绑 定 关 系 、 生 产 和 消费 的 方法 全 部 进行 封装 ， 这 样 对 于 应 用 来 说 好 比 在 操作 
=A G) 队列。 


为 了 将 封装 表述 地 更 加 清晰 ， 这 里 分 三 个 步骤 来 讲述 其 中 的 实现 细节 : (D) 声明 交换 器 、 
队列 、 绑 定 关系 ; OO 封装 生产 者 ; (3) 封装 消费 者 。 


不 管 是 哪个 步 又 ， 都 需要 先 与 Broker 建立 连接 ， 可 以 参考 代码 清单 7-13 中 AMQPPing 类 
的 实现 方式 来 完成 连接 的 逻辑 。 声 明 交 换 器 和 原先 的 实现 没有 什么 差别 ， 但 是 声明 队列 和 绑 定 
关系 就 需要 注意 了 ， 在 这 个 逻辑 队列 背后 是 多 个 实际 的 物理 队列 。 物 理 队列 的 个 数 需 要 事先 规 
划 好 ， 对 于 这 个 个 数 我 们 也 可 以 称 之 为 “分 片 数 ”， 即 代码 清单 9-1 中 的 subdivisionNum. 
假设 这 里 的 分 片 数 为 4 个 ， 那 么 实际 声明 队列 和 绑 定 关系 就 各 自 需 要 4 次 。 比 如 逻辑 队列 名 称 
为 “queue”， 那 么 就 需要 转变 为 类 似 “queue 0”“queue 1". *queue 2". *queue 3” 这 4 个 物 
PRA FU, JEDER EH SE US SEA "rk" EEJ "rk 0”“rk 1". "rk 2". "rk 3”， 最 后 达到 如 
9-8 所 示 的 效果 。 至 于 用 “_” 进 行 分 割 还 是 用 “@” 或 者 “#” 之 类 的 可 以 任凭 开发 者 的 喜 
好 ， 这 样 做 只 是 为 了 增加 辨识 E. 
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queue O 






exchange 


type-"direct" 


声明 交换 器 、 队 列 、 绑 定 关系 的 示例 代码 如 代码 清单 9-1 所 示 。 


ub 





/** 


* host. port. vhost, username. password 值 可 以 在 rmq cfg.properties RUE 
* 文件 中 配置 ， 可 以 复 用 代码 清单 7-17 中 的 相关 代码 


iod 

public class RmqEncapsulation ( 
private static String host - "localhost"; 
private static int port = 5672; 
private static String vhost - "/"; 
private static String username - "guest"; 
private static String password = "guest"; 


private static Connection connection; 


private int subdivisionNum;// 分 片 数 ， 表 示 一 个 逻辑 队列 背后 的 实际 队列 数 


public RmqEncapsulation(int subdivisionNum) { 
this.subdivisionNum - subdivisionNum; 

) 

// 创 建 Connection 

public static void newConnection() throws IOException, TimeoutException { 
ConnectionFactory connectionFactory - new ConnectionFactory(); 
connectionFactory.setHost (host); 
connectionFactory.setVirtualHost (vhost); 
connectionFactory.setPort (port); 
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connectionFactory.setUsername (username); 
connectionFactory.setPassword (password); 
connection - connectionFactory.newConnection(); 
} 
// 获 取 Connection, Xj null, MHH newConnection 进行 创建 
public static Connection getConnection() throws IOException, 
TimeoutException ( 
if (connection -- null) ( 
newConnection(); 
) 
return connection; 
) 
/ / XH] Connection 
public static void closeConnection() throws IOException ( 
if (connection !- null) { 
connection.close(); 


} 
} 
// 声 明 交换 器 


public void exchangeDeclare(Channel channel, String exchange, String type, 
boolean durable, boolean autoDelete, Map«String, Object» arguments) 
throws IOException ( 
channel.exchangeDeclare(exchange, type, durable, autoDelete, 
autoDelete, arguments); 
) 
// 声 明 队列 
public void queueDeclare(Channel channel, String queue, boolean durable, 
boolean exclusive, boolean autoDelete, Map«String, Object» arguments) 
throws IOException ( 
for (int i = 0; i < subdivisionNum; i-**) ( 
String queueName = queue + " " + i; 
channel.queueDeclare(queueName, durable, exclusive, autoDelete, 
arguments); 


} 


// 创 建 绑 定 关系 
public void queueBind (Channel channel, String queue, String exchange, String 
routingKey, Map<String, Object» arguments) throws IOException ( 
for (int i = 0; i < subdivisionNum; i++) ( 
String rkName = routingKey + " " + i; 
String queueName = queue + " " + i; 
channel.queueBind(queueName, exchange, rkName, arguments); 


) 


上 面 示 例 之 后 除了 基本 的 创建 和 关闭 Connection 的 方法 (newConnection 方法 、 
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getConnection 方法 和 closeConnection 方法 )， 还 有 exchangeDeclare 方法 、 

queueDeclare 方法 、queueBind 方法 分 别 用 来 声明 交换 器 、 队 列 及 绑 定 关系 。 注 意 
queueDeclare Jjik. queueBind 方法 中 名 称 转换 的 小 细节 。 这 里 方法 的 取 名 也 和 原生 客户 
端 中 的 名 称 相同 ， 这 样 可 以 尽量 保持 使 用 者 原 有 的 编程 思维 。 这 里 的 queueDeclare 方法 是 
针对 单个 Broker 的 情况 设计 的 , 如 果 集 群 中 有 多 个 节点 , queueDeclare 方法 需要 做 些 修改 ， 

使 得 分 片 队列 能 够 均匀 地 散 开 到 集群 中 的 各 个 节点 中 ， 以 达到 负载 均衡 的 目的 ， 具 体 实 现 可 以 
参考 代码 清单 7-6。 


代码 清单 9-2 中 演示 了 如 何 使 用 RmqEncapsulation 类 来 声明 交换 器 “exchange” 队列 





RmqEncapsulation rmqEncapsulation = new RmqEncapsulation (4); 

try í 
Connection connection = RmqEncapsulation.getConnection(); 
Channel channel = connection.createChannel(); 
rmqEncapsulation.exchangeDeclare (channel, "exchange", "direct", true, false, 


null); 
rmqEncapsulation.queueDeclare(channel, "queue", true, false, false, null); 
rmqEncapsulation.queueBind(channel, "queue", "exchange", "rk", null); 


) catch (IOException e) { 
e.printStackTrace(); 
) catch (TimeoutException e) ( 
e.printStackTrace(); 
) finally ( 
try ( 
RmqEncapsulation.closeConnection(); 
) catch (IOException e) ( 
e.printStackTrace(); 


} 


} 


生产 者 的 封装 代码 非常 简单 ， 只 需要 转换 下 原先 的 路 由 键 即 可 ， 代 码 清单 9-3 给 出 了 具体 
实现 。 





public void basicPublish(Channel channel, String exchange, String routingKey, 
boolean mandatory, AMQP.BasicProperties props, byte[] body) 
throws IOException { 


// 随 机 挑选 一 个 队列 发 送 
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Random random = new Random(); 

int index = random.nextInt(subdivisionNum); 

String rkName = routingKey + "_" + index; 
channel.basicPublish(exchange, rkName, mandatory, props, body); 


) 
basicPublish 方法 的 使 用 示例 如 下 : 


Channel channel = connection.createChannel(); 
for (int i20;i«100;i--*) { 
Message message = new Message (); 
message .setMsgSeq (i); 
message.setMsgBody("rabbitmq encapsulation"); 
byte[] body = getBytesFromObject (message); 
rmqEncapsulation.basicPublish(channel, "exchange", "rk", false, 
MessageProperties.PERSISTENT TEXT PLAIN, body); 
) 


代码 清单 9-3 中 演示 的 是 发 送 100 条 消息 的 情况 。 细 心 的 读者 可 能 会 注意 到 这 里 引入 了 两 
个 新 的 东西 :Message 类 和 getBytesFromobject 方 法 .Message 类 的 是 用 来 封装 消息 的 ， 
具体 定义 如 代码 清单 9-4 所 示 。 


Ying. 





public class Message implements Serializable( 
private static final long serialVersionUID = 1L; 
private long msgSeq; 
private String msgBody; 
private long deliveryTag; 


// 省 略 Getter 和 setter 方法 


GOverride 
public String toString()( 
return "[msgSeq-" + msgSeq 
+ ", msgBody-" + msgBody 
+ ", deliveryTag-" + deliveryTag 
e pte 


) 

Message 类 中 的 msgSeq 表示 消息 的 序号 ， 类 似 于 UUID， 但 这 个 是 有 序 的 ， 本 节 末 尾 的 内 
容 会 用 到 这 个 成 员 变 量 。msgBody 表示 消息 体 本 身 ， 这 里 只 是 简单 定义 为 String 类 型 ， 可 以 更 改 
成 其 他 任意 的 类 型 。deliveryTag 用 于 消息 确认 ， 详 细 可 以 参考 3.5 节 的 内 容 。Message 类 通过 


Serializable 接口 来 实现 序列 化 ， 这 里 只 是 方便 演示 ， 实 际 使 用 时 建议 采用 ProtoBuff 这 类 性 能 
较 高 的 序列 化 工具 。getBytesFromObject 方法 ， 还 有 与 其 对 应 的 getobjectFromBytes 7j 
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法 分 别 用 来 将 对 象 转换 为 字 节 数组 和 将 字 节 数组 转换 为 对 象 ， 具 体 的 实现 非常 简单 ， 可 以 参考 代码 





public static byte[] getBytesFromObject(Object object) throws IOException ( 
if (object == null) ( 
return null; 


) 
ByteArrayOutputStream bo - new ByteArrayOutputStream(); 


ObjectOutputStream oo - new ObjectOutputStream (bo); 
oo.writeObject (object); 

oo.close(); 

bo.close(); 

return bo.toByteArray(); 


} 
public static Object getObjectFromBytes (byte[] body) 


throws IOException, ClassNotFoundException { 
if (body == null || body.length == 0) { 
return null; 


} 
ByteArrayInputStream bi = new ByteArrayInputStream (body); 


ObjectInputStream oi = new ObjectInputStream (bi); 


oi.close(); 
bi.close(); 
return oi.readObject(); 


) 

图 9-9 展示 了 封装 后 的 逻辑 队列 ( 即 4 个 物理 队列 》 和 单个 独立 队列 之 间 的 QPS 对 比 ， 测 
试 环境 同 本 节 开 篇 所 述 。 可 以 看 到 封装 后 的 逻辑 队列 与 原先 的 单个 队列 相 比 性 能 提升 了 不 止 一 
倍 ， 可 以 得 出 打破 单个 队列 进程 的 性 能 瓶颈 的 结论 。 
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再 来 看 一 下 消费 者 的 封装 代码 ， 这 个 就 略微 显得 有 些 复杂 了 。 由 3.4 节 的 介绍 可 知 ， 
RabbitMQ 的 消费 分 推 模式 和 拉 模 式 。 相 对 于 推 模式 消费 的 封装 实现 ， 拉 模式 消费 的 封装 实现 还 
算 简 单 。 下 面 首先 演示 下 拉 模 式 的 封装 实现 ， 如 代码 清单 9-6 所 示 。 


— ENSEM 


tse 





public GetResponse basicGet(Channel channel, String queue, boolean autoAck) 
throws IOException { 
GetResponse getResponse = null; 
Random random = new Random (); 
int index = random.nextInt (subdivisionNum); 
getResponse = channel.basicGet (queue+" "+index,autoAck); 


if (getResponse == null) ( 
for(int i-0;i«subdivisionNum;i-*-*) ( 
String queueName = queue + "" + i; 
getResponse = channel.basicGet (queueName, autoAck); 
if (getResponse !- null) { 


return getResponse; 
} 
} 
} 
return getResponse; 


} 


以 上 代码 中 首先 随机 拉 取 一 个 物理 队列 中 的 数据 ， 如 果 返 回 为 空 ， 则 再 按 顺 序 拉 取 。 这 样 
实现 比 直接 顺序 拉 取 的 方式 要 好 很 多 ， 因 为 当 生 产 者 发 送 速度 大 于 消费 者 消费 速度 时 ， 顺 序 拉 
取 可 能 只 拉 取 到 第 一 个 物理 队列 的 数据 ， 即 “queue 0” 中 的 数据 ， 而 其 余 3 个 物理 队列 的 数据 
可 能 会 被 长 久 积压 。 


推 模式 的 封装 实现 需要 在 RmqEncapsulation 类 中 添加 一 个 concurrentLinkedDeque< 
Message> 类 型 的 成 员 变 量 blockingQueue， 用 来 缓存 推送 的 数据 以 方便 消费 者 消费 。 有 具体 
实现 逻辑 如 代码 清单 9-7 所 示 。 


public class RmqEncapsulation { 
// 省 略 host. port. vhost, username. password 的 定义 及 实现 
private static Connection connection; 
private int subdivisionNum;// 分 片 数 ， 表 示 一 个 逻辑 队列 背后 的 实际 队列 数 


private ConcurrentLinkedDeque<Message> blockingQueue; 








public RmqEncapsulation(int subdivisionNum) {// 修 改 了 构造 函数 的 实现 
this.subdivisionNum = subdivisionNum; 
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blockingQueue = new ConcurrentLinkedDeque«Message»(); 
) 
// 省 略 newConnection Jjik. getConnection Jjik. closeConnection 方法 的 实现 
// 省 略 exchangeDeclare Jjik. queueDeclare Jjik. queueBind 方法 的 实现 
// 省 略 basicPublish 方法 和 basicGet 方法 的 实现 
private void startConsume (Channel channel, String queue, boolean autoAck, 
String consumerTag, ConcurrentLinkedDeque«Message» newblockingQueue) 
throws IOException ( 
for (int i = 0; i < subdivisionNum; i++) ( 
String queueName = queue + " " + i; 
channel.basicConsume (queueName, autoAck, consumerTag + i, 
new NewConsumer (channel, newblockingQueue)); 


} 
public void basicConsume (Channel channel, String queue, boolean autoAck, 
String consumerTag, ConcurrentLinkedDeque<Message> newblockingQueue, 
IMsgCallback iMsgCallback) throws IOException { 
startConsume (channel, queue, autoAck, consumerTag, newblockingQueue); 
while (true) { 
Message message = newblockingQueue.peekFirst(); 
if (message !- null) ( 
ConsumeStatus consumeStatus - iMsgCallback.consumeMsg (message); 
newblockingQueue.removeFirst(); 


if (consumeStatus == ConsumeStatus.SUCCESS) { 
channel.basicAck(message.getDeliveryTag(), false); 
) else ( 


channel.basicReject (message.getDeliveryTag(),false); 
} 
}else{ 
try 4 
TimeUnit.MILLISECONDS.sleep (100); 
) catch (InterruptedException e) ( 
e.printStackTrace(); 


} 
public static class NewConsumer extends DefaultConsumer( 
private ConcurrentLinkedDeque«Message» newblockingQueue; 
public NewConsumer(Channel channel,ConcurrentLinkedDeque«Message» 
newblockingQueue) ( 
super (channel); 
this.newblockingQueue - newblockingQueue; 
} 
GOverride 
public void handleDelivery(String consumerTag, Envelope envelope, 
AMQP.BasicProperties properties, byte[] body) throws IOException { 


e 261 è 


RabbitMQ 实战 指南 


try ( 
Message message - (Message) getObjectFromBytes (body); 
message.setDeliveryTag (envelope.getDeliveryTag()); 
newblockingQueue.addLast (message); 

} catch (ClassNotFoundException e) ( 
e.printStackTrace(); 


) 


} 


代码 清单 9-7 的 篇 幅 有 点 较 长 ， 真 正在 使 用 推 模式 消费 时 调用 的 方法 为 basicConsume, 与 
原生 客户 端的 方法 channel.basicConsume 类 似 。 关 于 NewConsumer 这 个 内 部 类 就 不 多 做 介 
绍 , 其 功能 只 是 获取 Broker 中 的 数据 然后 存 入 RmaEncapsulation 的 成 员 变量 blockingoueue 
中 。 这 里 需要 关注 的 是 basicConsume 方法 中 的 IMsgCallback， 这 是 包含 一 个 回调 函数 
consumeMsg (Message message) 的 接口 ， consumeMsg 方法 返回 值 为 一 个 枚 举 类 型 
ConsumeStatus ， 当 消费 端 消 费 成 功 后 返回 ConsumeStatus.SUCCESS, ， 反 之 则 返回 
ConsumeStatus .FAIL。 有 关 IMsgCallback 接口 和 ConsumeStatus 的 枚 举 类 的 定义 如 代码 
清单 9-8 所 示 。 





public interface IMsgCallback { 
ConsumeStatus consumeMsg (Message message); 


} 

public enum ConsumeStatus { 
SUCCESS, 
FAIL 

) 


拉 模 式 的 消费 非常 简单 ， 这 里 就 不 做 演示 了 。 推 模式 的 消费 示例 如 下 : 


Channel channel = connection.createChannel(); 
channel.basicQos(64); 
rmqEncapsulation.basicConsume (channel, "queue", false, "consumer zzh", 
rmqEncapsulation.blockingQueue, new IMsgCallback() { 
QOverride 
public ConsumeStatus consumeMsg (Message message) ( 
ConsumeStatus consumeStatus - ConsumeStatus.FAIL; 
if (message!- null) { 
System.out.println (message); 
consumeStatus - ConsumeStatus.SUCCESS; 
) 


return consumeStatus; 
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注意 要 点 : 


为 了 简化 演示 ， 本 节 的 代码 示例 省 去 了 很 多 的 功能 ， 局 限 性 很 强 ， 比 如 没有 使 用 publisher 
confirm 机 制 ; 没有 设置 mandatory 参数 ; 只 能 使 用 一 个 Connection; 消息 没有 使 用 Protostuff 
这 种 性 能 较 高 的 序列 化 工具 进行 序列 化 和 反 序 列 化 ， 等 等 。 如 果 读者 要 借鉴 本 节 中 的 内 容 ， 建 
议 进 一 步 优 化 示例 代码 。 


这 里 还 有 一 个 问题 ， 在 上 面 的 封装 示例 中 消息 随机 发 送 和 随机 消费 都 会 影响 到 RabbitMQ 
本 身 消息 的 顺序 性 。 虽 然 在 4.9.2 节 中 我 们 做 过 分 析 ， 知 道 RabbitMQ 消息 本 身 的 顺序 性 比较 受 
限 ， 并 非 是 绝对 保证 ， 但 是 如 果 应 用 程序 要 求 有 一 定 的 顺序 性 ， 并 且 代 码 逻 辑 也 能 遵循 4.9.2 
节 中 顺序 性 的 要 求 ， 那 么 上 面 的 封装 示例 就 需要 修改 了 。 


如 图 9-10 所 示 ， 发 送 端 根据 Message 的 消息 序号 msgSeq 对 分 片 个 数 进行 取 模 运算 ， 之 
后 将 对 应 的 消息 发 送 到 对 应 的 队列 中 ， 这 样 消 息 可 以 均匀 且 顺 序 地 在 每 个 队列 中 存储 。 在 消费 
端 为 每 个 队列 创建 一 个 消息 权 (slot)， 从 队列 中 读 取 的 消息 都 存 入 对 应 的 槽 中 ， 发 送 到 下 游 的 
消息 可 以 依次 从 slot0 至 slot3 中 进行 读 取 。 更 严谨 的 做 法 是 根据 上 一 条 消息 的 msgseq, 从 slot0 
至 slot3 "Hi msgseq 的 消息 。 有 具体 的 代码 逻辑 这 里 就 不 袭 述 了 ， 留 给 读者 自己 实现 。 





9-10 顺序 性 的 消息 


94 ”镜像 队列 


WR RabbitMQ 集群 中 只 有 一 个 Broker 节点 ， 那 么 该 节点 的 失效 将 导致 整体 服务 的 临时 性 
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不 可 用 ， 并 且 也 可 能 会 导致 消息 的 丢失 。 可 以 将 所 有 消息 都 设置 为 持久 化 ， 并 且 对 应 队列 的 
durable 属性 也 设置 为 tue， 但 是 这 样 仍然 无 法 避免 由 于 缓存 导致 的 问题 : 因为 消息 在 发 送 之 
后 和 被 写 入 磁盘 并 执行 刷 盘 动作 之 间 存 在 一 个 短暂 却 会 产生 问题 的 时 间 窗 。 通 过 publisher 
confirm 机 制 能 够 确保 客户 端 知道 哪些 消息 已 经 存 入 磁盘 ， 尽 管 如 此 ， 一 般 不 希望 遇 到 因 单 点 故 
障 导致 的 服务 不 可 用 。 


如 果 RabbitMQ 集群 是 由 多 个 Broker 节点 组 成 的 ， 那 么 从 服务 的 整体 可 用 性 上 来 讲 ， 该 集 
群 对 于 单 点 故障 是 有 弹性 的 ， 但 是 同时 也 需要 注意 : 尽管 交换 器 和 绑 定 关 系 能 够 在 单 点 故障 问 
题 上 幸免 于 难 ， 但 是 队列 和 其 上 的 存储 的 消息 却 不 行 ， 这 是 因为 队列 进程 及 其 内 容 仅仅 维持 在 
单个 节点 之 上 ， 所 以 一 个 节点 的 失效 表现 为 其 对 应 的 队列 不 可 用 。 


引入 镜像 队列 (Mirror Queue) 的 机 制 , 可 以 将 队列 镜像 到 集群 中 的 其 他 Broker 节点 之 上 ， 
如 果 集 群 中 的 一 个 节点 失效 了 ， 队 列 能 自动 地 切换 到 镜像 中 的 男 一 个 节点 上 以 保证 服务 的 可 用 
性 。 在 通常 的 用 法 中 ， 针 对 每 一 个 配置 镜像 的 队列 (以 下 简称 镜像 队列 〉 都 包含 一 个 主 节点 
(master) 和 若干 个 从 节点 (slave)， 相 应 的 结构 可 以 参考 图 9-11。 





图 9-11 主 从 结构 


slave 会 准确 地 按照 master 执行 命令 的 顺序 进行 动作 ， 故 slave 与 master 上 维护 的 状态 应 该 
是 相同 的 。 如 果 master 由 于 某 种 原因 失效 ,那么 “资历 最 老 ” 的 slave 会 被 提升 为 新 的 master. 
根据 slave 加 入 的 时 间 排 序 ， 时 间 最 长 的 slave 即 为 “资历 最 老 ”。 发 送 到 镜像 队列 的 所 有 消息 会 
被 同时 发 往 master 和 所 有 的 slave 上 ,如 果 此 时 master Efi T, 消息 还 会 在 slave E, 这 样 slave 
提升 为 master 的 时 候 消息 也 不 会 丢失 。 除 发 送 消息 (Basic.Publish) 外 的 所 有 动作 都 只 会 
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向 master 发 送 ， 然 后 再 由 master 将 命令 执行 的 结果 广播 给 各 个 slave。 


如 果 消 费 者 与 slave 建立 连接 并 进行 订阅 消费 ， 其 实质 上 都 是 从 master 上 获取 消息 ， 只 不 
过 看 似 是 从 slave 上 消费 而 已 。 比 如 消费 者 与 slave 建立 了 TCP 连接 之 后 执行 一 个 Basic.Get 
的 操作 ， 那 么 首先 是 由 slave 将 Basic.Get 请 求 发 往 master， 再 由 master 准备 好 数据 返回 给 
slave， 最 后 由 slave 投递 给 消费 者 。 读 者 可 能 会 有 疑问 ， 大 多 的 读 写 压力 都 落 到 了 master E, 
那么 这 样 是 否 负载 会 做 不 到 有 效 的 均衡 ? 或 者 说 是 否 可 以 像 MySQL 一 样 能 够 实现 master 写 而 
slave 读 呢 ? 注意 这 里 的 master 和 slave 是 针对 队列 而 言 的 ， 而 队列 可 以 均匀 地 散落 在 集群 的 各 
个 Broker 节点 中 以 达到 负载 均衡 的 目的 ， 因 为 真正 的 负载 还 是 针对 实际 的 物理 机 器 而 言 的 ， 而 
不 是 内 存 中 驻 留 的 队列 进程 。 


在 图 9-12 中 ,集群 中 的 每 个 Broker 节点 都 包含 1 个 队列 的 master 和 2 个 队列 的 slave, Q1 
的 负载 大 多 都 集中 在 brokerl 上 ，Q2 的 负载 大 多 都 集中 在 broker2 上 ，Q3 的 负载 大 多 都 集中 在 
broker3 上 ， 只 要 确保 队列 的 master 节点 均匀 散落 在 集群 中 的 各 个 Broker 节点 即 可 确保 很 大 程 
度 上 的 负载 均衡 〈 每 个 队列 的 流量 会 有 不 同 ， 因 此 均匀 散落 各 个 队列 的 master 也 无 法 确保 绝对 
的 负载 均衡 )。 至 于 为 什么 不 像 MySQL 一 样 读 写 分 离 ，RabbitMQ 从 编程 逻辑 上 来 说 完全 可 以 
实现 ， 但 是 这 样 得 不 到 更 好 的 收益 ， 即 读 写 分 离 并 不 能 进一步 优化 负载 ， 却 会 增加 编码 实现 的 
复杂 度 ， 增 加 出 错 的 可 能 ， 显 得 得 不 偿 失 。 





9-12 ”集群 结构 


注意 要 点 : 
RabbitMQ 的 镜像 队列 同时 支持 publisher confirm 和 事务 两 种 机 制 。 在 事务 机 制 中 ， 只 有 当 
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前 事务 在 全 部 镜像 中 执行 之 后 ,客户 端 才 会 收 到 Tx.Commit-Ok 的 消息 。 同样 的 ,在 publisher 
confirm 机 制 中 ， 生 产 者 进行 当前 消息 确认 的 前 提 是 该 消息 被 全 部 进行 所 接收 了 。 


不 同 于 普通 的 非 镜像 队列 (参考 图 9-2)， 镜 像 队 列 的 backing queue 比较 特殊 ， 其 实现 
并 非 是 rabbit variable queue. 'EPPHEGLXE T 1658 backing queue 进行 本 地 消息 消息 
持久 化 处 理 ， 在 此 基础 上 增加 了 将 消息 和 ack 复制 到 所 有 镜像 的 功能 。 镜 像 队 列 的 结构 可 以 参 
考 图 9-13, master 的 backing queue 采用 的 是 rabbit mirror queue master. 而 slave 
f Jbacking queue 实现 是 rabbit mirror queue slave. 


rabbit mirror queue. slave rabbit mirror queue. slave 





图 9-13 镜像 队列 的 结构 


所 有 对 rabbit mirror queue master 的 操作 都 会 通过 组 播 GM(Guaranteed Multicast) 
的 方式 同步 到 各 个 slave 中 。GM 负责 消息 的 广播 ，rabbit mirror queue slave 负责 回 
调处 理 ， 而 master 上 的 回调 处 理 是 由 coordinator 负责 完成 的 。 如 前 所 述 ， 除 了 
Basic.Publish， 所 有 的 操作 都 是 通过 master 来 完成 的 ，master 对 消息 进行 处 理 的 同时 将 消 
息 的 处 理 通过 GM 广播 给 所 有 的 slave, slave 的 GM 收 到 消息 后 ， 通 过 回调 交 由 
rabbit mirror queue slave 进行 实际 的 处 理 。 

GM 模块 实现 的 是 一 种 可 靠 的 组 播 通信 协议 ， 该 协议 能 够 保证 组 播 消息 的 原子 性 ， 即 保证 
组 中 活着 的 节点 要 么 都 收 到 消息 要 么 都 收 不 到 ， 它 的 实现 大 致 为 : 将 所 有 的 节点 形成 一 个 循环 
链表 ， 每 个 节点 都 会 监控 位 于 自己 左右 两 边 的 节点 ， 当 有 节点 新 增 时 ， 相 邻 的 节点 保证 当前 广 
播 的 消息 会 复制 到 新 的 节点 上 ， 当 有 节点 失效 时 ， 相 邻 的 节点 会 接管 以 保证 本 次 广播 的 消息 会 
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复制 到 所 有 的 节点 。 在 master 和 slave 上 的 这 些 GM 形成 一 个 组 (gm_group)， 这 个 组 的 信息 
会 记录 在 Mnesia 中 。 不 同 的 镜像 队列 形成 不 同 的 组 。 操 作 命令 从 master 对 应 的 GM 发 出 后 ， 
顺 着 链表 传送 到 所 有 的 节点 。 由 于 所 有 节点 组 成 了 一 个 循环 链表 ，master 对 应 的 GM 最 终 会 收 
到 自己 发 送 的 操作 命令 ， 这 个 时 候 master 就 知道 该 操作 命令 都 同步 到 了 所 有 的 slave 上 。 


新 节点 的 加 入 过 程 可 以 参考 图 9-14， 整 个 过 程 就 像 在 链表 中 间 插 入 一 个 节点 。 注 意 每 当 一 
个 节点 加 入 或 者 重新 加 入 到 这 个 镜像 链 路 中 时 ， 之 前 队列 保存 的 内 容 会 被 全 部 清空 。 


bd 


A A B 
(master) (master) (slave1) 
i d ^ . 
^ t 


9-14 ”新 节点 的 加 入 过 程 


当 slave 挂 掉 之 后 ， 除 了 与 slave 相连 的 客户 端 连接 全 部 断 开 ， 没 有 其 他 影响 。 当 master f£ 
掉 之 后 ， 会 有 以 下 连锁 反应 : 

(1) 与 master 连接 的 客户 端 连接 全 部 断 开 。 

(2) 选举 最 老 的 slave 作为 新 的 master， 因 为 最 老 的 slave 与 旧 的 master 之 间 的 同步 状态 应 
该 是 最 好 的 。 如 果 此 时 所 有 slave 处 于 未 同步 状态 ， 则 未 同步 的 消息 会 丢失 。 


(3) 新 的 master 重新 入 队 所 有 unack 的 消息 ， 因 为 新 的 slave 无 法 区 分 这 些 unack 的 消息 是 
否 已 经 到 达 客 户 端 ， 或 者 是 ack 信息 丢失 在 老 的 master 链 路 上 ， 再 或 者 是 丢失 在 老 的 master 组 
播 ack 消息 到 所 有 slave 的 链 路 上 ， 所 以 出 于 消息 可 靠 性 的 考虑 ， 重 新 入 队 所 有 unack 的 消息 ， 
不 过 此 时 客户 端 可 能 会 有 重复 消息 。 


(4) 如 果 客 户 端 连 接着 slave， 并 且 Basic.Consume 消费 时 指定 了 x-cancel-on-ha- 
failover 参数 ， 那 么 断 开 之 时 客户 端 会 收 到 一 个 Consumer Cancellation Notification 的 通知 ， 
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消费 者 客户 端 中 会 回调 consumer 接口 的 handleCancel 方法 。 如 果 未 指定 x-cancel- 
on-ha-failover 参数 ， 那 么 消费 者 将 无 法 感知 master 宕 机 。 


x-cancel-on-ha-failover 参数 的 使 用 示例 如 下 : 


Channel channel = ...; 

Consumer consumer = ...; 

Map«String, Object» args = new HashMap«String, Object»(); 
args.put("x-cancel-on-ha-failover", true); 
channel.basicConsume ("my-queue", false, args, consumer); 


镜像 队列 的 配置 主要 是 通过 添加 相应 的 Policy 来 完成 的 ， 对 于 添加 Policy 的 细节 可 以 参考 
6.3 节 。 这 里 需要 详解 介绍 的 是 rabbitmqctl set policy [-p vhost] [--priority 
priority] [--apply-to apply-to] (name) (pattern) {definition} 命 令 中 的 
definition 部 分 ,对 于 镜像 队列 的 配置 来 说 , definition 中 需要 包含 3 个 部 分 :ha-mode、 


ha-params 和 ha-sync-mode。 


信 ha-mode: 指明 镜像 队列 的 模式 ， 有 效 值 为 al1l1、exactly、nodes， 默 认为 all。 
all 表示 在 集群 中 所 有 的 节点 上 进行 镜像 ，exactly 表示 在 指定 个 数 的 节点 上 进行 镜 
像 ， 节 点 个 数 由 ha-params 指定 ; nodes 表示 在 指定 节点 上 进行 镜像 ， 节 点 名 称 通 
过 ha-params 指定 ， 节 点 的 名 称 通常 类 似 于 rabbit@hostname ， 可 以 通过 
rabbitmqctl cluster status 命令 查看 到 。 


+% ha-params: 不 同 的 ha-mode 配置 中 需要 用 到 的 参数 。 
* ha-sync-mode: 队列 中 消息 的 同步 方式 ， 有 效 值 为 automatic manual. 


举 个 例子 ， 对 队列 名 称 以 “queue ”开头 的 所 有 队列 进行 镜像 ， 并 在 集群 的 两 个 节点 上 完 
成 镜像 ，Policy 的 设置 命令 为 : 


rabbitmqctl set policy --priority 0 --apply-to queues mirror queue "^queue " 
'("ha-mode":"exactly","ha-params":2,"ha-sync-mode":"automatic")"' 


ha-mode 参数 对 排他 〈exclusive) 队列 并 不 生效 ， 因 为 排他 队列 是 连接 独占 的 ， 当 连接 断 
开 时 队列 会 自动 删除 ， 所 以 实际 上 这 个 参数 对 排他 队列 没有 任何 意义 。 


将 新 节点 加 入 已 存在 的 镜像 队列 时 ， 默 认 情 况 下 ha-sync-mode 取 值 为 manual, 镜像 队 
列 中 的 消息 不 会 主动 同步 到 新 的 slave 中 ， 除 非 显 式 调用 同步 命令 。 当 调用 同步 命令 后 ， 队 列 开 
始 阻 塞 ， 无 法 对 其 进行 其 他 操作 ， 直 到 同步 完成 。 当 ha-sync-mode WAX automatic Hf, 
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新 加 入 的 slave 会 默认 同步 已 知 的 镜像 队列 。 由 于 同步 过 程 的 限制 , 所 以 不 建议 对 生产 环境 中 正 
在 使 用 的 队列 进行 操作 。 使 用 rabbitmqctl list queues (name) slave pids 
synchronised slave pids 命令 可 以 查看 哪些 slaves 已 经 完成 同步 。 通 过 手动 方式 同步 一 
个 队列 的 命令 为 rabbitmqctl sync queue {name}， 同 样 也 可 以 取消 某 个 队列 的 同步 操 


作 : rabbitmqctl cancel sync queue (name). 


当 所 有 slave 都 出 现 未 同步 状态 , 并 且 ha-promote-on-shutdown 设置 为 when-synced 
(默认 ) 时 ， 如 果 master 因为 主动 原因 停 掉 ， 比 如 通过 rabbitmqctl stop 命令 或 者 优雅 关闭 
操作 系统 ， 那 么 slave 不 会 接管 master， 也 就 是 此 时 镜像 队列 不 可 用 ; 但 是 如 果 master 因为 被 动 
原因 停 掉 ， 比 如 Erlang 虚拟 机 或 者 操作 系统 崩 演 ， 那 么 slave 会 接管 master。 这 个 配置 项 隐 含 的 
价值 取向 是 保证 消息 可 靠 不 丢 失 ， 同 时 放弃 了 可 用 性 。 如 果 ha-promote-on-shutdown 设置 
为 always， 那 么 不 论 master 因为 何 种 原因 停止 ，slave 都 会 接管 master， 优 先 保证 可 用 性 ， 不 过 
消息 可 能 会 丢失 。 


镜像 队列 中 最 后 一 个 停止 的 节点 会 是 master， 启 动 顺 序 必 须 是 master 先 启动 。 如 果 slave 
先 启动 , 它 会 有 30 秒 的 等 待 时 间 , 等 待 master 的 启动 , 然后 加 入 到 集群 中 。 如果 30 秒 内 master 
没有 启动 ，slave 会 自动 停止 。 当 所 有 节点 因 故 〈 断 电 等 ) 同时 离线 时 ， 每 个 节点 都 认为 自己 不 
是 最 后 一 个 停止 的 节点 ， 要 恢复 镜像 队列 ， 可 以 尝试 在 30 秒 内 启动 所 有 节点 。 


95 小 结 


本 章 首 先 讲述 了 RabbitMQ 的 存储 机 制 ， 进 而 对 队列 的 结构 展开 讨论 ， 队 列 中 的 消息 有 
alpha. beta. gamma. delta 这 4 种 状态 ， 内 部 存储 又 可 以 分 为 Ql1、Q2、Delta、Q3、Q4 
这 5 个 子 队 列 。 消 息 会 在 这 5 个 子 队 列 中 流转 ， 为 了 性 能 的 提升 需要 尽 可 能 地 避免 消息 过 量 堆 
积 。 如 果 消 息 是 持久 化 的 ， 建 立 搭 配 惰性 队列 使 用 ， 这 样 在 提升 性 能 的 同时 还 可 以 降低 内 存 的 
损耗 。 内 存 、 磁 盘 和 流 控 都 是 用 来 限制 消息 流入 得 过 快 以 避免 相应 的 服务 进程 来 不 及 处 理 而 崩 
溃 。 镜 像 队 列 的 引入 可 以 极 大 地 提升 RabbitMQ 的 可 用 性 及 可 靠 性 ， 提 供 了 数据 见 余 备份 、 避 
免 单 点 故障 的 功能 ， 强 烈 建议 在 实际 应 用 中 为 每 个 重要 的 队列 都 配置 镜像 。 
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网 络 分 区 是 在 使 用 RabbitMQ 时 所 不 得 不 面 对 的 一 个 问题 ， 网 络 分 区 的 发 生 可 能 会 引起 消 
息 竺 失 或 者 服务 不 可 用 等 。 可 以 简单 地 通过 重启 的 方式 或 者 配置 自动 化 处 理 的 方式 来 处 理 这 个 
问题 ， 但 深究 其 里 会 发 现 网 络 分 区 不 是 想象 中 的 那么 简单 。 本 章 通过 网 络 分 区 的 意义 、 影 响 、 
处 理 及 案例 分 析 等 多 个 维度 来 一 一 剖析 其 中 的 奥秘 。 
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10.1 网 络 分 区 的 意义 


RabbitMQ 集群 的 网 络 分 区 的 容错 性 并 不 是 很 高 ， 一 般 都 是 使 用 Federation 或 者 Shovel 来 
解决 广域网 中 的 使 用 问题 。 不 过 即使 是 在 局 域 网 环境 下 ， 网 络 分 区 也 不 可 能 完全 人 避免， 网 络 
设备 〈 比 如 中 继 设 备 、 网 卡 ) 出 现 故 障 也 会 导致 网 络 分 区 。 当 出 现 网 络 分 区 时 ， 不 同 分 区 里 
的 节点 会 认为 不 属于 自身 所 在 分 区 的 节点 都 已 经 挂 (down) 了 ， 对 于 队列 、 交 换 器 、 绑 定 的 
操作 仅 对 当前 分 区 有 效 。 在 RabbitMQ 的 默认 配置 下 , 即使 网 络 恢复 了 也 不 会 自动 处 理 网 络 分 
区 带 来 的 问题 。RabbitMQ 从 3.1 版 本 开始 会 自动 探测 网 络 分 区 ， 并 且 提 供 了 相应 的 配置 来 解 
决 这 个 问题 。 

当 一 个 集群 发 生 网 络 分 区 时 ， 这 个 集群 会 分 成 两 个 部 分 或 者 更 多 ， 它 们 各 自 为 政 ， 互 相 都 
认为 对 方 分 区 内 的 节点 已 经 挂 了 ， 包 括 队列 、 交 换 器 及 绑 定 等 元 数据 的 创建 和 销毁 都 处 于 自身 
分 区 内 ， 与 其 他 分 区 无 关 。 如 果 原 集群 中 配置 了 镜像 队列 ， 而 这 个 镜像 队列 又 牵涉 两 个 或 者 更 
多 个 网 络 分 区 中 的 节点 时 ， 每 一 个 网 络 分 区 中 都 会 出 现 一 个 master 节点 ， 对 于 各 个 网 络 分 区 ， 
此 队列 都 是 相互 独立 的 。 当 然 也 会 有 一 些 其 他 未 知 的 、 怪 异 的 事情 发 生 。 当 网 络 恢复 时 ， 网 络 
分 区 的 状态 还 是 会 保持 ， 除 非 你 采取 了 一 些 措施 去 解决 它 。 


如 果 你 没有 经 历 过 网 络 分 区 , 就 不 算 真正 掌握 RabbitMQ。 网 络 分 区 带 来 的 影响 大 多 是 负面 
的 ， 极 端 情况 下 不 仅 会 造成 数据 丢失 ， 还 会 影响 服务 的 可 用 性 。 


或 许 你 不 禁 要 问 ， 既 然 网 络 分 区 会 带 来 如 此 负面 的 影响 ， 为 什么 RabbitMQ 还 要 引入 网 络 
分 区 的 设计 理念 呢 ? 其 中 一 个 原因 就 与 它 本 身 的 数据 一 致 性 复制 原理 有 关 ， 如 上 一 章 所 述 ， 
RabbitMQ 采用 的 镜像 队列 是 一 种 环形 的 逻辑 结构 ， 如 图 10-1 所 示 。 


图 10-1 中 为 某 队 列 配置 了 4 个 镜像 ， 其 中 A 节点 作为 master 节点 ， 其 余 B、C RI D 节点 
作为 slave 节点 ，4 个 镜像 节点 组 成 一 个 环形 结构 。 假 如 需要 确认 (ack) 一 条 消息 ， 先 会 在 A 
节点 即 master 节点 上 执行 确认 命令 ， 之 后 转向 B 节点 ， 然 后 是 C 和 DD 节点， 最 后 由 DD 将 执行 
操作 返回 给 A 节点 ， 这 样 才 真 正确 认 了 一 条 消息 ， 之 后 才 可 以 继续 相应 的 处 理 。 这 种 复制 原理 
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和 ZooKeeper! 的 Quorum? 原理 不 同 ， 它 可 以 保证 更 强 的 一 致 性 。 在 这 种 一 致 性 数据 模型 下 ， 如 
果 出 现 网 络 波动 或 者 网 络 故障 等 异常 情况 ， 那 么 整个 数据 链 的 性 能 就 会 大 大 降低 。 如 果 C 节点 
网 络 异 常 ， 那 么 整个 A 一 B 一 C 一 D 一 A 的 数据 链 就 会 被 阻塞 ， 继 而 相关 服务 也 会 被 阻塞 ， 所 以 
这 里 就 需要 引入 网 络 分 区 来 将 异常 的 节点 剥离 出 整个 分 区 ， 以 确保 RabbitMQ 服务 的 可 用 性 及 
可 靠 性 。 等 待 网 络 恢复 之 后 ， 可 以 进行 相应 的 处 理 来 将 此 前 的 异常 节点 加 入 集群 中 。 


yw 
^ 


A B 
(master) (slave) 


图 10-1 环形 逻辑 结构 


网 络 分 区 对 于 RabbitMQ 本 身 而 言 有 利 有 弊 ， 读 者 在 遇 到 网 络 分 区 时 不 必 过 于 惊慌 。 许 多 
情况 下 ， 网 络 分 区 都 是 由 单个 节点 的 网 络 故障 引起 的 ， 且 通常 会 形成 一 个 大 分 区 和 一 个 单 节点 
的 分 区 ， 如 果 之 前 又 配置 了 镜像 ， 那 么 可 以 在 不 影响 服务 可 用 性 ， 不 丢失 消息 的 情况 下 从 网 络 
分 区 的 情形 下 得 以 恢复 。 


10.2 网络 分 区 的 判定 
RabbitMQ 集群 节点 内 部 通信 端口 默认 为 25672， 两 两 节点 之 间 都 会 有 信息 交互 。 如 果 某 节 


! ZooKeeper 是 一 个 分 布 式 的 、 开 源 的 分 布 式 应 用 程序 协调 服务 ， 是 Google 的 Chubby 的 一 个 开源 实现 ， 是 Hadoop 和 Hbase 的 
重要 组 件 。 它 是 一 个 为 分 布 式 应 用 提供 一 致 性 服务 的 软件 ， 提 供 的 功能 包括 : 配置 维护 、 域 名 服务 、 分 布 式 同步 、 组 服务 等 。 
? Quorum 是 一 种 分 布 式 系统 中 常用 的 ， 用 来 保证 数据 元 余 和 最 终 一 致 性 的 投票 算法 。 
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点 出 现 网 络 故障 ， 或 者 是 端口 不 通 ， 则 会 致使 与 此 节点 的 交互 出 现 中 断 ， 这 里 就 会 有 个 超时 判 
定 机制 ， 继 而 判定 网 络 分 区 。 


对 于 网 络 分 区 的 判定 是 与 net ticktime 这 个 参数 息息相关 的 ， 此 参数 默认 值 为 60 秒 。 
注意 与 heartbeat_time 的 区 别 , heartbeat time 是 指 客户 端 与 RabbitMQ 服务 之 间 通 信 
的 心跳 时 间 ， 针 对 5672 端口 而 言 。 如 果 发 生 超时 则 会 有 net tick timeout. 的 信息 报 出 。 在 
RabbitMQ 集群 内 部 的 每 个 节点 之 间 会 每 隔 四 分 之 一 的 net_ticktime 计 一 次 应 答 (tick)。 如 
果 有 任何 数据 被 写 入 节点 中 ， 则 此 节点 被 认为 已 经 被 应 答 (ticked) 了 。 如 果 连 续 4 次 ， 某 节点 
都 没有 被 ticked， 则 可 以 判定 此 节点 已 处 于 “down” 状 态 ， 其 余 节点 可 以 将 此 节点 剥离 出 当前 
分 区 。 


将 连续 4 次 的 tick 时 间 记 为 T, WA T 的 取 值 范围 为 : 0.75xnet ticktime < T < 
1.25xnet ticktime. [E 10-2 可 以 形象 地 描绘 出 这 个 取 值 范围 的 缘由 。 


! | 
Been l25xticktime =+ 
| 
1 
1 


-一 0 一 9 一 0 一 0 一 9 一 上 -一 


i i 
le- 075xticktime ——»! 


i i 
10-2” 取 值 范 围 的 缘由 


图 10-2 中 每 个 节点 代表 一 次 tick HERRER, E 2 个 临界 值 0.75xnet_ticktime 和 
1.25xnet ticktime 之 间 可 以 连续 执行 4 次 的 tick 判定 。 默 认 情 况 下 , 在 45s < T < 75s 
之 间 会 判定 出 net_tick_timeout。 


RabbitMQ 不 仅 会 将 队列 、 交 换 器 及 绑 定 等 信息 存储 在 Mnesia 数据 库 中 ， 而 且 许 多 围绕 网 
络 分 区 的 一 些 细节 也 都 和 这 个 Mnesia 的 行为 相关 。 如 果 一 个 节点 不 能 在 T 时 间 连 上 另 一 个 节点 ， 
那么 Mnesia 通常 认为 这 个 节点 已 经 挂 了 ， 就 算 之 后 两 个 节点 又 重新 恢复 了 内 部 通信 , 但 是 这 两 
个 节点 都 会 认为 对 方 已 经 挂 了 ，Mnesia 此 时 认定 了 发 生 网 络 分 区 的 情况 。 这 些 会 被 记录 到 
RabbitMQ 的 服务 日 志 之 中 ， 如 下 : 


=ERROR REPORT==== 16-0ct-2017::18:20:55 === 
Mnesial('rabbit@nodel'): ** ERROR ** mnesia event got 
(inconsistent database, running partitioned network, 'rabbit68node2'] 


除了 通过 查看 RabbitMQ 服务 日 志 的 方式 ,还 有 以 下 3 种 方法 可 以 查看 是 否 出 现 网 络 分 区 。 
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第 一 种 ， 采 用 rabbitmqctl 工具 来 查看 ， 即 采用 rabbitmqctl cluster status fij 
令 。 通 过 这 条 命令 可 以 看 到 集群 相关 信息 ， 未 发 生 网 络 分 区 时 的 情形 举例 如 下 : 


[(nodes, [(disc, [rabbit@nodel, rabbit@node2, rabbit@node3]}]}, 
(running nodes, [rabbit@node2, rabbit@node3, rabbit@node1]}, 
(cluster name,««"rabbit8nodel"»»], 

(partitions, [])] 


由 上 面 的 信息 可 知 ， 集 群 中 一 共有 3 个 节点 ， 分 别 为 rabbit@nodel rabbit(gnode2 和 
rabbit@node3 。 在 partitions 这 一 项 中 没有 相关 记录 ， 则 说 明 没 有 产生 网 络 分 区 。 如 果 
partitions 项 中 有 相关 内 容 ， 则 说 明 产生 了 网 络 分 区 ， 例 如 : 


[(nodes, [{disc, [rabbit@node1l, rabbit@node2, rabbit@node3]}]}, 
(running nodes, [rabbit@node3,rabbit@nodel]}, 
{cluster name,<<"rabbit@nodel">>}, 
(partitions, [{rabbit@node3, [rabbit@node2]}, {rabbit@nodel, [rabbit@node2] }]}] 


上 面 partitions 项 中 的 内 容 表 示 : 
(1) rabbit@node3 与 rabbit@node2 发 生 了 分 区 ， 即 {rabbit@node3, [rabbit@node2]}。 
(2) rabbit@nodel 与 rabbit@node2 发 生 了 分 区 ， 即 {rabbit@node3, [rabbit@node2]}。 


第 二 种 ， 通 过 Web 管理 界面 的 方式 查看 。 如 果 出 现 了 图 10-3 这 种 告警 ， 即 发 生 了 网 络 分 
区 。 也 推荐 读者 采用 这 种 方式 来 检测 是 否 发 生 了 网 络 分 区 。 


Network partition detected 


Mnesia reports that this RabbitMQ cluster has experienced a network 
partition. There is a risk of losing data. Please read 


The nature of the partition is as follows: 


| Node | Was partitioned from 
'rabbitenodel rabbit@node2 


rabbit&node2 | rabbitenode1 
rabbitenode3 


rabbitGnode3 rabbit@node2 


While running in this partitioned state, changes (such as queue or exchange declaration 
and binding) which take place in one partition will not be visible to other partition(s). 
Other behaviour is not guaranteed. 


图 10-3 网络 分 区 的 告警 
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第 三 种 ， 通 过 HTTP API 的 方式 调 取 节点 信息 来 检测 是 否 发 生 网 络 分 区 。 比 如 通过 curl 命 
令 来 调 取 节点 信息 : 


curl -i -u root:root123 -H "content-type:application/json" -X GET http:// 
localhost:15672/api/nodes 


注意 这 里 的 localhost 为 相应 的 RabbitMQ 服务 器 的 IP 地 址 。/api/nodes 这 个 接口 返 
回 一 个 JSON 字符 串 ， 详 细 内 容 可 以 参考 附录 A， 其 中 会 有 partitions 的 相关 项 ， 如 果 在 其 
中 发 现 partitions 项 中 有 内 容 则 为 发 生 了 网 络 分 区 。 举 例 ， 将 node2 分 离 出 nodel 和 node3 
的 主 分 区 之 后 ， 调 用 /api /nodes 这 个 接口 的 部 分 信息 : 


"sockets used": 1, 

"Sockets used details": { 
"rate": 0 

Fe 

"partitions": [ 
"rabbit@node2" 

I, 

"Os pid": "2156, 

"fd total": 1024, 

"sockets total": 829, 


上 面 信息 的 加 粗 部 分 即 为 JSON 字符 串 中 rabbit@nodel 节点 所 看 到 的 partitions 信息 ， 
由 此 可 以 判定 出 nodel 和 node2 发 生 了 网 络 分 区 。 


10.3 ”网 络 分 区 的 模拟 


正常 情况 下 ， 很 难 观察 到 RabbitMQ 网 络 分 区 的 发 生 。 为 了 更 好 地 理解 网 络 分 区 ， 需 要 采 
取 某 些 手段 将 其 模拟 出 来 ， 以 便 对 其 进行 相应 的 分 析 处 理 ， 进 而 在 实际 应 用 环境 中 遇 到 类 似 情 
形 ， 可 以 让 你 的 处 理 游 所 有 余 。 往 长 远方 面 讲 ， 也 可 以 采取 一 些 必要 的 手段 去 规避 网 络 分 区 的 
发 生 ， 或 者 可 以 监控 网 络 分 区 以 及 准备 相关 的 处 理 预案 。 


模拟 网 络 分 区 的 方式 有 多 种 ， 主 要 分 为 以 下 3 大 类 : 
* iptables 封禁 / 解 封 IP 地 址 或 者 端口 号 。 
信 关闭 /开启 网 卡 。 
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€ 挂 起 /恢复 操作 系统 。 


1. iptables 的 方式 


由 于 RabbitMQ 集群 内 部 节点 通信 端口 默认 为 25672， 可 以 封禁 这 个 端口 来 模拟 出 
net tick_timeout， 然 后 再 开启 此 端口 让 集群 判定 网 络 分 区 的 发 生 。 举例 说 明 ， 整 个 RabbitMQ 集 
群 由 3 个 节点 组 成 ， 分 别 为 nodel 、node2 和 node3。 此 时 我 们 要 模拟 node2 节点 被 剥离 出 当前 
分 区 的 情形 ， 即 模拟 [nodel，node3] 和 [node2] 两 个 分 区 。 可 以 在 node2 上 执行 如 下 命令 以 封禁 
25672 端口 。 如 果 在 配置 中 修改 过 这 个 端口 号 ， 将 下 面 的 命令 改 成 相应 的 端口 号 即 可 。 


iptables -A INPUT -p tcp --dport 25672 -j DROP 
iptables -A OUTPUT -p tcp --dport 25672 -j DROP 


同时 需要 监测 各 个 节点 的 服务 日 志 ， 当 有 如 下 相似 信息 出 现时 即 为 已 经 判定 出 
net tick timeout: 
-INFO REPORT---- 10-0ct-2017::11:53:03 === 


rabbit on node rabbitnode2 down 


-INFO REPORT---- 10-0ct-2017::11:53:03 === 
node rabbit8node2 down: net tick timeout 


当然 ， 如 果 不 想 这 么 麻烦 地 去 监测 各 个 节点 的 服务 日 志 ， 那 么 也 可 以 等 待 75 秒 (45s «T 
< 75s) 之 后 以 确保 出 现 net_tick_timeout。 注 意 此 时 只 判定 出 net_tick_timeout， 要 等 node2 网 
络 恢复 之 后 ， 即 解 封 25672 端口 之 后 才 会 判定 出 现 网 络 分 区 。 解 封 命令 如 下 : 


iptables -D INPUT 1 
iptables -D OUTPUT 1 


至 此 ，node2 节点 与 其 他 节点 的 内 部 通信 已 经 恢复 ， 如 果 此 时 查看 集群 的 状态 可 以 发 现 
[nodel, node3] 和 [node2] 已 形成 两 个 独立 的 分 区 。 


除 此 之 外 ， 还 可 以 使 用 iptables 封禁 IP 地 址 的 方法 模拟 网 络 分 区 。 假 设 整个 RabbitMQ 
集群 的 节点 名 称 与 其 IP 地址 对 应 如 下 : 


nodel 192.168.0.2 
node2 192.168.0.3 
node3 192.168.0.4 


如 果 要 模拟 出 [nodel, node3] 和 [node2] 两 个 分 区 的 情形 ， 可 以 在 node2 节点 上 执行 : 


iptables -I INPUT -s 192.168.0.2 -j DROP 
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iptables -I INPUT -s 192.168.0.4-j DROP 


对 应 的 解 封 命令 为 : 


iptables -D INPUT 1 
iptables -D INPUT 1 


或 者 也 可 以 分 别 在 nodel 和 node3 节点 上 执行 : 


iptables -I INPUT -s 192.168.0.3 -j DROP 


与 其 对 应 的 解 封 命令 为 : 


iptables -D INPUT 1 


如 果 集 群 的 节点 部 署 跨 网 段 ， 可 以 采取 禁用 整个 网 络 段 的 方式 模拟 网 络 分 区 。 假 设 
RabbitMQ 集群 中 3 个 节点 和 其 对 应 的 IP 关系 如 下 : 

nodel 192.168.0.2 

node2 192.168.1.3 // 注 意 这 里 的 网 段 

node3 192.168.0.4 


模拟 出 [nodel, node3] 和 [node2] 两 个 分 区 的 情形 ， 可 以 在 node2 节点 上 执行 : 


iptables -I INPUT -s 192.168.0.0/24 -j DROP 


对 应 的 解 封 命令 也 是 iptables -D INPUT 1. 


2. 封禁 / 解 封 网 卡 的 方式 


操作 网 卡 的 方式 和 iptables 的 方式 有 相似 之 处 ， 都 是 模拟 网 络 故障 来 产生 网 络 分 区 。 首 
先 需要 使 用 ifconfig 命令 来 查询 出 当前 的 网 卡 编号 ， 如 下 所 示 ， 一 般 情 况 下 单 台 机 器 只 有 一 
个 网 卡 〈 这 里 暂时 不 考虑 多 网 卡 的 情形 ， 因 为 对 于 RabbitMQ 来 说 ， 多 网 卡 的 情况 造成 的 网 络 
分 区 异常 复杂 ， 这 个 在 后 面 的 内 容 中 会 有 详细 阐述 。) 


[root@nodel rabbit@nodel]# ifconfig 

eth0 Link encap:Ethernet HWaddr FA:16:3E:A8:FF:31 

inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.224.0 
inet6 addr: fe80::f816:3eff:fea8:f£31/64 Scope:Link 

UP BROADCAST RUNNING MULTICAST MTU:1450 Metric:1 

RX packets:547632449 errors:0 dropped:0 overruns:0 frame:0 
TX packets:5745162 errors:0 dropped:0 overruns:0 carrier:0 
collisions:0 txqueuelen:1000 

RX bytes:82813557343 (77.1 GiB) TX bytes:3099664440 (2.8 GiB) 
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lo Link encap:Local Loopback 

inet addr:127.0.0.1 Mask:255.0.0.0 

inet6 addr: ::1/128 Scope:Host 

UP LOOPBACK RUNNING MTU:65536 Metric:1 

RX packets:111152 errors:0 dropped:0 overruns:0 frame:0 
TX packets:111152 errors:0 dropped:0 overruns:0 carrier:0 
collisions:0 txqueuelen:0 

RX bytes:5401343 (5.1 MiB) TX bytes:5401343 (5.1 MiB) 


同样 假设 nodel, node2 和 node3 这 三 个 节点 组 成 RabbitMQ 集群 ，node2 的 网 卡 编号 为 
eth0， 此 时 要 模拟 网 络 分 区 [nodel, node3] 和 [node2] 的 情形 ， 需 要 在 node2 上 执行 以 下 命令 关 
闭 网 卡 : 

ifdown eth0 

待 判 定 出 net tick timeout 之 后 ， 再 开启 网 卡 : 


ifup ethO 


这 样 就 可 以 模拟 出 网 络 分 区 。 当 然 也 可 以 使 用 service network stop 和 service 
network start 这 两 个 命令 来 模拟 网 络 分 区 ， 原 理 同 ifdown/ifup eth0 的 方式 。 


3. 挂 起 /恢复 操作 系统 的 方式 


除了 模拟 网 络 故 障 的 方式 ， 操 作 系 统 的 挂 起 和 恢复 操作 也 会 导致 集群 内 节点 的 网 络 分 区 。 
因为 发 生 挂 起 的 节点 不 会 认为 自身 已 经 失败 或 者 停止 工作 , 但 是 集群 内 的 其 他 节点 会 这 么 认为 。 
如 果 集 群 中 的 一 个 节点 运行 在 一 台 笔 记 本 电脑 上 ， 然 后 你 合 上 了 笔记 本 电脑 ， 那 么 这 个 节点 就 
挂 起 了 。 或 者 一 个 更 常见 的 现象 ， 集 群 中 的 一 个 节点 运行 在 某 台 虚拟 机 上 ， 然 后 虚拟 机 的 管理 
程序 挂 起 了 这 个 虚拟 机 节点 ， 这 样 节点 就 被 挂 起 了 。 在 等 待 了 (0.75xnet ticktime, 
1.25xnet_ticktime) 这 个 区 间 大 小 的 时 间 之 后 ， 判 定 出 net_tick_timeout， 再 恢复 挂 起 的 节 
点 即 可 以 复 现 网 络 分 区 。 


本 节 模 拟 的 都 是 单 节点 脱离 主 分 区 的 情形 ， 对 于 分 裂 成 对 称 的 网 络 分 区 和 多 网 络 分 区 的 情 
形 模拟 将 在 后 面 的 内 容 中 详细 介绍 ， 其 中 细节 也 是 从 单 节点 剥离 出 主 分 区 的 情形 衍生 而 来 的 。 
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10.4 ”网 络 分 区 的 影响 


RabbitMQ 集群 在 发 生 网 络 分 区 之 后 对 于 数据 可 靠 性 和 服务 可 用 性 方面 会 有 什么 样 的 影响 ? 
对 于 客户 端的 表现 又 是 怎样 的 ? 这 里 主要 针对 未 配置 镜像 和 配置 镜像 两 种 情况 展开 探讨 。 


10.4.1 未 配置 镜像 


nodel, node2 和 node3 这 3 个 节点 组 成 一 个 RabbitMQ 集群 ， 且 在 这 三 个 节点 中 分 别 创建 
queuel, queue2 和 queue3 这 三 个 队列 ， 并 且 相 应 的 交换 器 与 绑 定 关系 如 下 ; 
节点 名 称 交换 器 绑 定 队列 


nodel exchange rki queuel 
node2 exchange  rk2 queue2 
node3 exchange  rk3 queue3 


nodel 那 条 信息 表示 : 在 nodel 节点 上 创建 了 队列 queue1， 并 通过 路 由 键 rkl 与 交换 器 
exchange 进行 了 绑 定 。 


在 网 络 分 区 发 生 之 前 ， 客 户 端 分 别 连接 nodel 和 node2 并 分 别 向 queuel 和 queue2 发 送 消 
息 ， 对 应 关系 如 情形 10-1 所 示 。 





客户 端 节点 名 称 交换 器 绑 定 队列 
client1 node1 exchange rkl queuel 
client2 node2 exchange  rk2 queue2 


clientl 那 条 信息 表示 : 客户 端 clientl 连接 nodel 的 IP 地 址 ， 并 通过 路 由 键 rkl 向 交换 器 
exchange 发 送 消息 。 如 果 发 送 成 功 ， 消 息 可 以 存 入 队列 queuel 中 。 其 对 应 的 发 送 代码 如 下 : 


channel.basicPublish("exchange", "rkl", true, 
MessageProperties.PERSISTENT TEXT PLAIN, message.getBytes()); 


采用 iptables 封禁 / 解 封 25672 端口 的 方式 模拟 网 络 分 区 , 使 nodel 和 node2 存在 于 两 个 
不 同 的 分 区 之 中 ， 对 于 客户 端 clientl 和 client2 而 言 ， 没 有 任何 异常 ， 消 息 正常 发 送 也 没有 消息 
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丢失 。 如 果 这 里 采用 关闭 /开启 网 卡 的 方式 来 模拟 网 络 分 区 ， 在 关闭 网 卡 的 时 候 客户 端的 连接 也 
会 关闭 ， 这 样 就 检测 不 出 在 网 络 分 区 发 生 时 对 客户 端的 影响 。 


下 面 我 们 再 转换 一 下 思路 ， 如 果 上 面 的 clientl 连接 nodel 的 IP, J queue? 发 送 消息 会 
发 生 何 种 情形 。 新 的 对 应 关系 参考 情形 10-2。 
— ya 


客户 端 节点 名 称 ” ”交换 器 HE ”队列 
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clientl nodel exchange  rk2 queue2 
client2 node2 exchange rkl queuel 


这 里 同样 采用 iptables 的 方式 模拟 网 络 分 区 , 使 得 nodel 和 node2 处 于 两 个 不 同 的 分 区 。 
如 果 客 户 端 在 发 送 消息 的 时 候 将 mandatory 参数 设置 为 true， 那 么 在 网 络 分 区 之 后 可 以 通过 
抓 包工 具 〈 如 wireshark 等 ) 看 到 有 Basic.Return 将 发 送 的 消息 返回 过 来 。 这 里 表示 在 发 生 
网 络 分 区 之 后 ,clientl 不 能 将 消息 正确 地 送 达 到 queue2 中 , 同样 client2 不 能 将 消息 送 达到 queuel 
中 。 如 果 客 户 端 中 设置 了 ReturnListener 来 监听 Basic.Return 的 信息 , 并 附带 有 消息 重 
传 机 制 ， 那 么 在 整个 网 络 分 区 前 后 的 过 程 中 可 以 保证 发 送 端的 消息 不 丢失 。 


在 网 络 分 区 之 前 ，queuel 进程 存在 于 nodel 节点 中 ，queue2 的 进程 存在 于 node2 节点 中 。 
在 网 络 分 区 之 后 ， 在 nodel 所 在 的 分 区 并 不 会 创建 新 的 queue2 进程 ， 同 样 在 node2 所 在 的 分 区 
也 不 会 创建 新 的 queuel 的 进程 。 这 样 在 网 络 分 区 发 生 之 后 ， 虽 然 可 以 通过 rabbitmqctl 
list queues name 命令 在 nodel 节点 上 查看 到 queue2， 但 是 在 nodel 上 已 经 没有 真实 的 
queue2 进程 的 存在 。 


[root@nodel ~]# rabbitmqctl list queues name 
Listing queues ... 

queuel 

queue2 

queue3 


client 将 消息 发 往 交 换 器 exchange 之 后 并 不 能 路 由 到 queue2 中 , 因此 消息 也 就 不 能 存储 。 
如 果 客 户 端 没 有 设置 mandatory 参数 并 且 没 有 通过 Returnbistener 进行 消息 重 试 (或 者 
其 他 措施 ) 来 保障 消息 可 靠 性 ， 那 么 在 发 送 端 就 会 有 消息 丢失 。 

上 面 讨 论 的 是 消息 发 送 端的 情况 , 下 面 来 探讨 网 络 分 区 对 消费 端的 影响 。 在 网 络 分 区 之 前 ， 
分 别 有 客 户 端 连接 nodel 和 node2 并 订阅 消费 其 上 队列 中 的 消息 ， 其 对 应 关系 参考 情形 10-3. 
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客户 端 节点 名 称 队列 
client3 nodel queuel 
client4 node2 queue2 


client3 那 条 信息 表示 : client3 连接 nodel 的 ip 并 订阅 消费 queue1。 模 拟 网 络 分 区 置 nodel 
和 node2 于 不 同 的 分 区 之 中 。 在 发 生 网 络 分 区 的 前 后 ， 消 费 端 client3 和 client4 都 能 正常 消费 ， 
无 任何 异常 发 生 。 


参考 情形 10-2, 将 情形 10-3 中 的 消费 队列 交换 一 下 , 即 client3 连接 nodel 的 卫 消 费 queue2， 
其 对 应 关系 如 情形 10-4 所 示 。 





客户 端 节点 名 称 队列 
client3 nodel queue2 
client4 node2 queuel 


模拟 网 络 分 区 ， 将 nodel 与 node 置 于 两 个 不 同 的 分 区 。 在 发 生 网 络 分 区 前 ， 消 费 一 切 正 
常 。 在 网 络 分 区 发 生 之 后 ， 虽 然 客户 端 没有 异常 报错 ， 且 可 以 消费 到 相关 数据 ， 但 是 此 时 会 有 
一 些 怪 异 的 现象 发 生 ， 比 如 对 于 已 消费 消息 的 ack 会 失效 。 在 从 网 络 分 区 中 恢复 之 后 ， 数 据 不 
EK. 


如 果 分 区 之 后 ， 重 启 client3 或 者 有 个 新 的 客户 端 client5 连接 nodel 的 人 PP 来 消费 queue2, 
则 会 有 如 下 报错 : 


com.rabbitmq.client.ShutdownSignalException: channel error; protocol method: 

fmethod«channel.close» (reply-code-404, reply-text-NOT FOUND - home node 
'rabbit8node2' of durable queue 'queue2' in vhost '/' is down or inaccessible, 
class-id-60, method-id-20) 


同样 在 nodel 的 服务 日 志 中 也 有 相关 记录 ; 


-ERROR REPORT==== 12-0ct-2017::14:14:48 === 
Channel error on connection <0.9528.9> (192.168.0.9:61294 -> 192.168.0.2:5672, 
vhost: '/', user: 'root'), channel 1: 
[(amqp error,not found, 
"home node 'rabbit8(node2' of durable queue 'queue2' in vhost '/' 
is down or inaccessible", 
'basic.consume') 


综 上 所 述 ， 对 于 未 配置 镜像 的 集群 ， 网 络 分 区 发 生 之 后 ， 队 列 也 会 伴随 着 宿主 节点 而 分 散 


e281。 


RabbitMQ 实战 指南 


在 各 自 的 分 区 之 中 。 对 于 消息 发 送 方 而 言 ， 可 以 成 功 发 送 消息 ， 但 是 会 有 路 由 失败 的 现象 ， 需 
要 需要 配合 mandatory 等 机 制 保障 消息 的 可 靠 性 。 对 于 消息 消费 方 来 说 ， 有 可 能 会 有 诡异 、 
不 可 预知 的 现象 发 生 ， 比 如 对 于 已 消费 消息 的 ack 会 失效 。 如 果 网 络 分 区 发 生 之 后 ， 客 户 端 与 
某 分 区 重新 建立 通信 链 路 ， 其 分 区 中 如 果 没 有 相应 的 队列 进程 ， 则 会 有 异常 报 出 。 如 果 从 网 络 
分 区 中 恢复 之 后 ， 数 据 不 会 丢失 ， 但 是 客户 端 会 重复 消费 。 


10.4.2 已 配置 镜像 








如 果 集 群 中 配置 了 镜像 队列 ， 那 么 在 发 生 网 络 分 区 时 ， 情 形 比 未 配置 镜像 队列 的 情况 复杂 
得 多 ， 尤 其 是 发 生 多 个 网 络 分 区 的 时 候 。 这 里 先 简 单 地 从 3 个 节点 分 裂 成 2 个 网 络 分 区 的 情形 
展开 讨论 。 如 前 一 节 所 述 ， 集 群 中 有 nodel. node2 和 node3 这 3 个 节点 ， 分 别 在 这 些 节点 上 创 
建 队 列 queuel. queue2 和 queue3， 并 配置 镜像 队列 。 采 用 iptables 的 方式 将 集群 模拟 分 裂 
成 nodel, node3] 和 [node2] 这 两 个 网 络 分 区 。 


镜像 队列 的 相关 配置 可 以 参考 如 下 : 


ha-mode:exactly 
ha-param:2 
ha-sync-mode:automatic 


首先 来 分 析 第 一 种 情况 。 如 情形 10-5-1 所 示 ，3 个 队列 的 master 镜像 和 slave 镜像 分 别 做 
相应 分 布 。 





情形 10-5-1 ”分 区 之 前 i " T PUR 
队列 master slave 
queuel nodel node3 
queue2 node2 node3 
queue3 node3 node2 


在 发 生 网 络 分 区 之 后 , [nodel, node3] 分 区 中 的 队列 有 了 新 的 部 署 。 除 了 queuel 未 发 生 改 变 ， 
queue2 由 于 原宿 主 节点 node2 已 被 剥离 当前 分 区 ， 那 么 node3 提升 为 master， 同 时 选择 nodel 
作为 slave。 在 queue3 es nen nodel indi slave. WIRE m 10-5-2. 


情形 10-5-2 分 区 之 后 


| [nodel, node3] 4M | Rn 
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队列 | master slave | master slave 
queuel | nodel node3 | nodel node3 
queue2 | node3 nodel | node2 [] 
queue3 | node3 nodel | node2 [] 


对 于 [node2] 分 区 而 言 ，queue2 和 queue3 的 分 布 比较 容易 理解 ， 此 分 区 中 只 有 一 个 节点 ， 
所 有 slave 这 一 列 为 空 。 但 是 对 于 queuel 而 言 ， 其 部 署 还 是 和 分 区 前 如 出 一 略 。 不 管 是 在 网 络 
分 区 前 ， 还 是 在 网 络 分 区 之 后 ， 再 或 者 是 又 从 网 络 分 区 中 恢复 ， 对 于 queuel 而 言 生 产 和 消费 消 
息 都 不 会 受到 任何 的 影响 ， 就 如 未 发 生 过 网 络 分 区 一 样 。 对 于 队列 queue2 和 queue3 的 情形 可 
以 参考 上 面 未 配置 镜像 的 相关 细节 ， 从 网 络 分 区 中 恢复 〈 即 恢复 成 之 前 的 [nodel, node2, node3] 
组 成 的 完整 分 区 ) 之 后 可 能 会 有 数据 丢失 。 

再 考虑 另 一 种 情形 ， 分 区 之 前 如 情形 10-6-1 所 示 。 


Ut 





队列 master slave 


queuel nodel node2 
queue2 node2 node3 
queue3 node3 nodel 











队列 | master slave | master slave 
queuel | nodel node3 | node2 [] 
queue2 |  node3 nodel |  node2 [] 
queue3 | node3 nodel | node3 nodel 


有 兴趣 的 读者 可 以 自行 演练 或 者 实地 操作 剩余 的 情形 ， 并 通过 客户 端 验 证 其 数据 可 靠 性 等 
方面 。 我 们 知道 可 以 在 指定 节点 上 创建 相应 的 队列 ， 但 是 如 何在 ha-mode=exactly 和 
ha-params-2 的 镜像 配置 下 准确 地 指定 对 应 的 slave 镜像 所 在 节点 呢 ? 如 果 要 实现 情形 10-6-1 
的 分 布 ， 可 以 实现 编写 一 个 脚本 ， 命 名 为 rmq_mirror_create.sh， 具 体内 容 如 下 : 


rabbitmqctl clear policy pl 

rabbitmqctl set policy --priority 0 --apply-to queues pl ".*" 
' ("ha-mode" : "exactly","ha-params":2)]' 

rabbitmqctl list queues name pid slave pids 


之 后 再 为 rmq mirror create.sh 添加 可 执行 权限 : 
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chmod a*x rmq mirror create.sh 


最 后 反复 运行 脚本 直到 有 如 下 相似 输出 即 可 (主要 是 观察 list_queues 中 slave pids 
的 信息 ): 


[root@nodel ~]# ./ rmq mirror create.sh 
Clearing policy "pl" ... 
Setting policy "pl" for pattern '.*" to 
"(N"ha-modeV":N"exactlyNV", \"ha-params\":2}" with priority "0" ... 
Listing queues ... 
queuel «rabbit8nodel.1.279.0» [«rabbit8node2.3.3804.1»] 
queue2 «rabbitG8node2.3.1391.1» [«rabbit8node3.1.10567.0»] 
queue3 «rabbit6node3.1.9625.0» [«rabbit8nodel.1.13080.1»5] 


前 面 讨 论 的 镜像 配置 都 是 ha-sync-mode-automatic 的 情形 ， 当 有 新 的 slave 出 现时 ， 
此 slave 会 自动 同步 master 中 的 数据 。 注 意 在 同步 的 过 程 中 ， 集 群 的 整个 服务 都 不 可 用 ， 客 户 
端 连接 会 被 阻塞 。 如 果 master 中 有 大 量 的 消息 堆积 ， 必 然 会 造成 slave 的 同步 时 间 增 长 ， 进 一 
步 影 响 了 集群 服务 的 可 用 性 。 如 果 配 置 na-sync-mode=manual， 有 新 的 slave 创建 的 同时 不 
会 去 同步 master 上 旧 的 数据 ， 如 果 此 时 master 节点 又 发 生 了 异常 ， 那 么 此 部 分 数据 将 会 丢失 。 
同样 ha-promote-on-shutdown 这 个 参数 的 影响 也 需要 考虑 进来 。 


网 络 分 区 的 发 生 可 能 会 引起 消息 的 丢失 ， 当 然 这 点 也 有 办 法 解决 。 首 先 消息 发 送 端 要 有 能 
够 处 理 Basic.Return 的 能 力 。 其 次 ， 在 监测 到 网 络 分 区 发 生 之 后 ， 需 要 迅速 地 挂 起 所 有 的 
生产 者 进程 。 之 后 连接 分 区 中 的 每 个 节点 消费 分 区 中 所 有 的 队列 数据 。 在 消费 完 之 后 再 处 理 网 
络 分 区 。 最 后 在 从 网 络 分 区 中 恢复 之 后 再 恢复 生产 者 的 进程 。 整 个 过 程 可 以 最 大 程度 上 保证 网 
络 分 区 之 后 的 消息 的 可 靠 性 。 同 样 也 要 注意 的 是 ， 在 整个 过 程 中 会 伴 有 大 量 的 消息 重复 ， 消 费 
者 客户 端 需要 做 好 相应 的 究 等 性 处 理 。 当 然 也 可 以 采用 7.4 节 中 的 集群 迁移 ， 将 所 有 旧 集 群 的 
资源 都 迁移 到 新 集群 来 解决 这 个 问题 。 


10.5 ”手动 处 理 网 络 分 区 


为 了 从 网 络 分 区 中 恢复 ,首先 需要 挑选 一 个 信任 分 区 ,这 个 分 区 才 有 决定 Mnesia 内 容 的 权 
限 ， 发 生 在 其 他 分 区 的 改变 将 不 会 被 记录 到 Mnesia 中 而 被 直接 丢弃 。 在 挑选 完 信 任 分 区 之 后 ， 
重启 非 信任 分 区 中 的 节点 ， 如 果 此 时 还 有 网 络 分 区 的 告警 ， 紧 接着 重启 信任 分 区 中 的 节点 。 
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这 里 有 3 个 要 点 需要 详细 阐述 : 
€ 如 何 挑选 信任 分 区 ? 

€ 如 何 重启 节点 ? 

9 重启 的 顺序 有 何 考究 ? 


挑选 信任 分 区 一 般 可 以 按照 这 几 个 指标 进行 :分 区 中 要 有 dise 节点 ;分 区 中 的 节点 数 最 多 ; 
分 区 中 的 队列 数 最 多 ; 分 区 中 的 客户 端 连接 数 最 多 。 优先 级 从 前 到 后 , 例如 信任 分 区 中 要 有 disc 
节点 ; 如 果 有 两 个 或 者 多 个 分 区 满足 ， 则 挑选 节点 数 最 多 的 分 区 作为 信任 分 区 ; 如 果 又 有 两 个 
或 者 多 个 分 区 满足 ， 那 么 挑选 队列 数 最 多 的 分 区 作为 信任 分 区 。 依 次 类 推 ， 如 果 有 两 个 或 者 多 
个 分 区 对 于 这 些 指 标 都 均等 ， 那 么 随机 挑选 一 个 分 区 也 不 失 为 一 良策 。 


RabbitMQ 中 有 两 种 重启 方式 : 第 一 种 方式 是 使 用 rabbitmqctl stop 命令 关闭 ， 然 后 
再 用 rabbitmq-server -detached 命令 启动 ; 第 二 种 方式 是 使 用 rabbitmqcti 
stop app 关闭 ， 然 后 使 用 rabbitmqctl start app 命令 启动 。 第 一 种 方式 需要 同时 重启 
Erlang 虚拟 机 和 RabbitMQ 应 用 ， 而 第 二 种 方式 只 是 重启 RabbitMQ 应 用 。 两 种 方式 都 可 以 从 网 
络 分 区 中 恢复 , 但 是 更 加 推荐 使 用 第 二 种 方式 ,包括 下 一 节 所 讲述 的 自动 处 理 网 络 分 区 的 方式 ， 
其 内 部 也 是 采用 的 第 二 种 方式 进行 重启 节点 。 


RabbitMQ 的 重启 顺序 也 比较 讲究 ， 必 须 在 以 下 两 种 重启 顺序 中 择 其 一 进行 重启 操作 : 


(1) 停止 其 他 非 信任 分 区 中 的 所 有 节点 ， 然 后 再 启动 这 些 节点 。 如 果 此 时 还 有 网 络 分 区 的 
告警 ， 则 再 重启 信任 分 区 中 的 节点 以 去 除 告警 。 


(2) 关闭 整个 集群 中 的 节点 ， 然 后 再 启动 每 一 个 节点 ， 这 里 需要 确保 启动 的 第 一 个 节点 在 
信任 的 分 区 之 中 。 


在 选择 哪 种 重启 顺序 之 前 ， 首 先 考虑 一 下 队列 “漂移 ”的 现象 。 所 谓 的 队列 “漂移 ”是 在 
配置 镜像 队列 的 情况 下 才 会 发 生 的 。 假 设 一 共 集 群 中 有 nodel、node2 和 node3 这 3 个 节点 ， 且 
配置 全 镜像 (ha-mode=all)， 具 体 如 情形 10-7-1 所 示 。 





队列 master slaves 


queuel nodel node2, node3 
queue2 node2 node3, nodel 
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Gueue3 node3 


node2, nodel 


这 里 首先 关闭 node3 节点 ,那么 queue3 中 的 某 个 slave 提升 为 master, 具体 变化 为 情形 10-7-2. 





队列 master 
queuel nodel 
queue2 node2 
queue3 node2 
然后 在 再 关闭 node2 节点 ， 





队列 master 


queuel nodel 
queue2 nodel 
queue3 nodel 


继续 演变 为 情形 10-7-3. 


slaves 
node2 
nodel 
nodel 








slaves 
[] 
[] 
[1 


此 时 , 如 果 关 闭 nodel 节点 , 然后 再 启动 这 3 个 节点 。 或 者 不 关闭 nodel 节点 , 而 启动 node2 
和 node3 节点 都 只 会 增加 slave 的 个 数 ， 而 不 会 改变 master 的 分 布 ， 最 终 如 情形 10-7-4 所 示 。 
注意 这 里 哪怕 关闭 了 nodel, 然后 并 非 先 启动 nodel, 而 是 先 启动 node2 或 者 node3, 对 于 master 
节点 的 分 布 都 不 会 受 影响 。 






队列 master 
queuel nodel 
queue2 nodel 
queue3 nodel 








slaves ( 按 节点 启动 顺序 排列 ) 
node2, node3 


node2, node3 
node2, node3 





这 里 就 可 以 看 出 ， 随 着 节点 的 重启 ， 所 有 的 队列 的 master 都 “漂移 ”到 了 nodel 节点 上 ， 
因为 在 RabbitMQ 中 ， 除 了 发 布 消息 ， 所 有 的 操作 都 是 在 master 上 完成 的 ， 如 此 大 部 分 压力 都 
集中 到 了 nodel 节点 上 ， 从 而 不 能 很 好 地 实现 负载 均衡 。 


基于 情形 10-7-2, 考虑 另外 一 种 情形 。 如 果 在 关闭 节点 node3 之 后 , 又 重新 启动 节点 node3， 





那么 会 有 如 情形 10-7-5 的 变化 。 
队列 master 
queuel nodel 
queue2 node2 
queue3 node2 
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slaves 

node2, node3 
nodel, node3 
nodel, node3 
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之 后 再 重启 ERA, 后 月 动 》 node2 节点 ， 如 情形 10-7-6 所 示 。 





情形 107-6 - TERT Lead ee rad d nio vb 3s 
队列 master slaves 
queuel nodel node3, node2 
queue2 nodel node3, node2 
queue3 nodel node3, node2 


继续 重启 nodel Tg 如 情形 10-7-7 





T iig n $ um: e eL EC us "THU a M 
) 形 10-7 | m 人 de 
队列 master slaves 
queuel node3 node2, nodel 
queue2 node3 node2, nodel 
queue3 node3 node2, nodel 


如 此 顺序 演变 , 在 配置 镜像 的 集群 中 重启 会 有 队列 “漂移 ”的 情况 发 生 , 造成 负载 不 均衡 。 
这 里 采用 的 是 全 镜像 以 作 说 明 ， 读 者 可 以 自行 推理 对 于 2 个 节点 ha-mode-exactly 且 ha- 
params-2 的 镜像 配置 的 演变 过 程 。 不 管 如 何 ， 都 难以 避免 队列 “漂移 ”的 发 生 。 


注意 要 点 : 


一 定 要 按照 前 面 提 及 的 两 种 方式 择 其 一 进行 重启 。 如 果 选 择 挨个 节点 重启 的 方式 ， 同 样 可 
以 处 理 网 络 分 区 ， 但 是 这 里 会 有 一 个 严重 的 问题 ， 即 Mnesia 内 容 权限 的 归属 问题 。 比 如 有 两 个 
分 区 [nodel, node2] 和 [node3, node4]， 其 中 [nodel, node2] 为 信任 分 区 。 此 时 若 按照 挨个 重启 的 方 
式 进 行 重启 ， 比 如 先 重 局 node3， 在 node3 节点 启动 之 时 无 法 判断 其 节点 的 Mnesia 内 容 是 向 
[nodel, node2] 分 区 靠 齐 还 是 向 node4 节点 靠 齐 。 至 此 ， 如 果 挨 个 一 轮 重 启 之 后 ， 最 终 集群 中 的 
Mnesia 数据 是 [node3, node4] 这 个 非 信 任 分 区 ， 就 会 造成 无 法 估量 的 损失 。 挨 个 节点 重启 也 有 可 
能 会 引起 二 次 网 络 分 区 的 发 生 。 


如 果 原 本 配置 了 镜像 队列 ， 从 发 生 网 络 分 区 到 恢复 的 过 程 中 队列 可 能 会 出 现 “ 漂 移 ”的 现 
象 。 可 以 重启 之 前 先 删除 镜像 队列 的 配置 ， 这 样 能 够 在 一 定 程度 上 阻止 队列 的 “过 分 漂移 ” 即 
阻止 可 能 所 有 队列 都 “漂移 ”到 一 个 节点 上 的 情况 。 


删除 镜像 队列 的 配置 可 以 采用 rabbitmacti 工具 删除 : 


rabbitmqctl clear policy [-p vhost] (mirror queue name) 


可 以 通过 Web 管理 界面 进行 删除 ， 也 可 以 通过 HTTP API 的 方式 进行 删除 : 
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curl -s -u [(username:password) -X DELETE 
http://localhost:15672/api/policies/default/(mirror queue name] 


注意 ， 如 果 事 先 没 有 开启 RabbitMQ Management 插件 ， 那 么 只 能 使 用 rabbitmqctl 工具 
的 方式 。 与 此 同时 ， 需 要 在 每 个 分 区 上 都 执行 删除 镜像 队列 配置 的 操作 ， 以 确保 每 个 分 区 中 的 
镜像 都 被 删除 。 


具体 的 网 络 分 区 处 理 步 骤 如 下 所 述 。 


€ 步骤 1: 挂 起 生产 者 和 消费 者 进程 ,这 样 可 以 减少 消息 不 必要 的 丢失 , 如 果 进 程 数 过 多 ， 
情形 又 比较 紧急 ， 也 可 跳 过 此 步骤 。 


步骤 2: 删除 镜像 队列 的 配置 。 
步骤 3: 挑选 信任 分 区 。 
步骤 4: 关闭 非 信 任 分 区 中 的 节点 。 采 用 rabbitmqctl stop app 命令 关闭 。 


步骤 5: 启动 非 信 任 分 区 中 的 节点 。 采 用 与 步骤 4 对 应 的 rabbitmqctl start app 
命令 启动 。 


€ 步骤 6: 检查 网 络 分 区 是 否 恢复 ， 如 果 已 经 恢复 则 转 步骤 8; 如 果 还 有 网 络 分 区 的 报警 
则 转 步 又 7. 


v 步骤 7: 重启 信任 分 区 中 的 节点 。 
仿 步骤 8: 添加 镜像 队列 的 配置 。 
€ 步骤 9: 恢复 生产 者 和 消费 者 的 进程 。 


这 里 还 剩 下 最 后 一 个 问题 : 如 何 判断 已 经 从 网 络 分 区 中 恢复 ? 这 个 可 以 对 照 着 10.2 一 节 进 
行 说 明 。 可 以 使 用 rabbitmqctl cluster_status 命令 检测 其 输出 的 partitions 这 一 项 
中 是 否 有 节点 信息 ， 如 果 为 空 则 说 明 已 经 恢复 。 如 果 在 Web 管理 界面 中 看 到 无 任何 网 络 分 区 的 
告警 ， 也 可 说 明 已 经 恢复 。 当 然 通 过 HTTP API 的 方式 来 判断 也 是 一 种 有 效 的 手段 。 
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10.6 自动 处 理 网络 分 区 


RabbitMQ 提供 了 三 种 方法 自动 地 处 理 网 络 分 区 : pause-minority 模式 、pause-if-all-down 模式 
和 autoheal 模式 。 默 认 是 ignore 模式 ， 即 不 自动 处 理 网 络 分 区 ， 所 以 在 这 种 模式 下 ， 当 网 络 分 区 的 
时 候 需 要 人 工 介 入 。 在 rabbitmq.config 配置 文件 中 配置 cluster partition handling 
参数 即 可 实现 相应 的 功能 。 默 认 的 ignore 模式 的 配置 如 下 ， 注 意 最 后 有 个 点 号 : 


[ 
{ 
rabbit, [ 
(cluster partition handling, ignore] 


] 


10.6.1 pause-minority 模式 


在 pause-minority 模式 下 ， 当 发 生 网 络 分 区 时 ， 集 群 中 的 节点 在 观察 到 某 些 节点 “down” 
的 时 候 ， 会 自动 检测 其 自身 是 否 处 于 “少数 派 ”( 分 区 中 的 节点 小 于 或 者 等 于 集群 中 一 半 的 节点 
数 )，RabbitMQ 会 自动 关闭 这 些 节 点 的 运作 。 根 据 CAP 原理 ， 这 里 保障 了 P， 即 分 区 耐 受 性 。 
这 样 确保 了 在 发 生 网 络 分 区 的 情况 下 ， 大 多 数 节点 〈 当 然 这 些 节点 得 在 同一 个 分 区 中 ) 可 以 继 
续 运 行 。“ 少 数 派 ”中 的 节点 在 分 区 开始 时 会 关闭 ， 当 分 区 结束 时 又 会 启动 。 这 里 关闭 是 指 
RabbitMQ 应 用 的 关闭 ， 而 Erlang 虚拟 机 并 不 关闭 ， 类 似 于 执行 了 rabbitmqctl stop app 
命令 。 处 于 关闭 的 节点 会 每 秒 检测 一 次 是 否 可 连通 到 剩余 集群 中 , 如 果 可 以 则 启动 自身 的 应 用 。 
相当 于 执行 rabbitmqctl start app 命令 。 


pause-minority 模式 相应 的 配置 如 下 : 


3 CAP 原理 又 称 CAP 定理 ， 指 的 是 在 一 个 分 布 式 系统 中 ，Consistency (一 致 性 )、Availability (可 用 性 ) 和 Partition tolerance 
(分 区 耐 受 性 ) 三 者 不 可 兼 得 。 


e289。 








RabbitMQ 实战 指南 


{ 
rabbit, [ 
(cluster partition handling, pause minority) 


] 
l. 


需要 注意 的 是 ，RabbitMQ 也 会 关闭 不 是 严格 意义 上 的 大 多 数 ， 比 如 在 一 个 集群 中 只 有 两 个 
节点 的 时 候 并 不 适合 采用 pause-minority 的 模式 , 因为 其 中 任何 一 个 节点 失败 而 发 生 网 络 分 区 时 ， 
两 个 节点 都 会 关闭 。 当 网 络 恢复 时 ， 有 可 能 两 个 节点 会 自动 启动 恢复 网 络 分 区 ， 也 有 可 能 仍 保 
持 关 闭 状 态 。 然 而 如 果 集 群 中 的 节点 数 远 大 于 2 个 时 , pause minority 模式 比 ignore 模式 更 加 可 
靠 ， 特 别 是 网 络 分 区 通常 是 由 单 节点 网 络 故 障 而 脱离 原 有 分 区 引起 的 。 


不 过 也 需要 考虑 2v2, 3v3 这 种 被 分 裂 成 对 等 节点 数 的 分 区 的 情况 。 所 谓 的 2v2 这 种 对 等 分 
区 表示 原 有 集群 的 组 成 为 [nodel, node2, node3, node4]， 由 于 某 种 原因 分 裂 成 类 似 [nodel, node2] 
和 [node3, node4] 这 两 个 网 络 分 区 的 情形 。 这 种 情况 在 跨 机 架 部 署 时 就 有 可 能 发 生 ， 当 nodel 和 
node2 部 署 在 机 架 A 上 ， 而 node3 和 node4 部 署 在 机 架 B 上 ， 那 么 有 可 能 机 架 A 与 机 架 B 之 间 
网 络 的 通 断 会 造成 对 等 分 区 的 出 现 。 


在 10.3 节 中 只 阐述 了 如 何 模 拟 网 络 分 区 ， 并 没有 明确 说 明 如 何 模 拟 对 等 的 网 络 分 区 。 可 以 
在 nodel 和 node2 上 分 别 执行 iptables 命令 去 封禁 node3 和 node4 HJ IP. WHR nodel、node2 
和 node3、node4 处 于 不 同 的 网 段 , 那么 也 可 以 采用 封禁 网 段 的 做 法 。 更 有 甚 者 , 可 以 将 nodel、 
node2 部 署 到 物理 机 A 上 的 两 台 虚 拟 机 中 ,然后 将 node3、node4 部 署 到 物理 机 B 上 的 两 台 虚 拟 
机 中 ， 之 后 切断 物理 机 A 与 B 之 间 的 通信 即 可 。 


当 对 等 分 区 出 现时 ， 会 关闭 这 些 分 区 内 的 所 有 节点 ， 对 于 前 面 的 [nodel, node2] 和 [node3， 
node4] 的 例子 而 言 ， 这 四 个 节点 上 的 RabbitMQ 应 用 都 会 被 关闭 。 只 有 等 待 网 络 恢复 之 后 ， 才 会 
自动 启动 所 有 的 节点 以 求 从 网 络 分 区 中 恢复 。 





10.6.2 pause-if-all-down 模式 


在 pause-if-all-down 模式 下 ，RabbitMQ 集群 中 的 节点 在 和 所 配置 的 列表 中 的 任何 节点 不 能 
交互 时 才 会 关闭 ， 语法 为 {pause if all down, [nodes], ignore|autoheal); 其 中 
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[nodes ] 为 前 面 所 说 的 列表 ， 也 可 称 之 为 受信 节点 列表 。 参 考 配 置 如 下 : 


[ 
rabbit, [ 
(cluster partition handling, 
(pause if all down, ['rabbit8nodel'], ignore]] 


]. 


如 果 一 个 节点 与 rabbit@nodel 节点 无 法 通信 时 ， 则 会 关闭 自身 的 RabbitMQ 应 用 。 如 果 是 
rabbit@nodel 本 身 发 生 了 故障 造成 网 络 不 可 用 ， 而 其 他 节点 都 是 正常 的 情况 下 ， 这 种 规则 会 让 
所 有 的 节点 中 RabbitMQ 应 用 都 关闭 ， 待 rabbit@nodel 中 的 网 络 恢复 之 后 ， 各 个 节点 再 启动 自 
身 应 用 以 从 网 络 分 区 中 恢复 。 


注意 到 pause-if-all-down 模式 下 有 ignore 和 autoheal 两 种 不 同 的 配置 。 考 虑 前 面 
pause-minority 模式 中 提 及 的 一 种 情形 ，nodel 和 node2 部 署 在 机 架 A E, mi node3 和 node4 部 
署 在 机 架 B 上 。 此 时 配置 {cluster partition handling, (pause if all down, 
['rabbit8nodel', 'rabbit8node3'], ignore]], JJ HLR A 和 机 架 B 的 通信 出 现 
异常 时 ， 由 于 nodel 和 node2 保持 着 通信 ，node3 和 node4 保持 着 通信 ， 这 4 个 节点 都 不 会 自行 
关闭 ， 但 是 会 形成 两 个 分 区 ， 所 以 这 样 不 能 实现 自动 处 理 的 功能 。 所 以 如 果 将 配置 中 的 ignore 
替换 成 autoheal 就 可 以 处 理 此 种 情形 。 


10.6.8 mutohed| WS —— — nm 


在 autoheal 模式 下 ， 当 认为 发 生 网 络 分 区 时 ，RabbitMQ 会 自动 决定 一 个 获胜 (winning) 
的 分 区 ， 然 后 重启 不 在 这 个 分 区 中 的 节点 来 从 网 络 分 区 中 恢复 。 一 个 获胜 的 分 区 是 指 客户 端 连 
接 最 多 的 分 区 ， 如 果 产 生 一 个 平局 ， 即 有 两 个 或 者 多 个 分 区 的 客户 端 连接 数 一 样 多 ， 那 么 节点 
数 最 多 的 一 个 分 区 就 是 获胜 分 区 。 如 果 此 时 节点 数 也 一 样 多 ， 将 以 节点 名 称 的 字典 序 来 挑选 获 
胜 分 区 ， 相 关 的 源码 “如 代码 清单 10-1 所 示 。 
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 autoheal 的 源码 地 址 : https:/github.com/rabbitmq/rabbitmq-server/blob/master/src/rabbit autoheal.erl. 
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make decision (AllPartitions)-> 
Sorted = lists:sort([(partition value(P),P) || P <- AllPartitions]), 
[[Winner | ] | Rest] = lists:reverse([P || ( , P) <- Sorted]), 
(Winner, lists:append(Rest)). 

partition value(Partition) 一 > 


Connections = [Res || Node «- Partition, 
Res <- [rpc:call (Node, rabbit networking, 
Connections local, [])], 


is list(Res)], 
(length(lists:append(Connections)), length(Partition)]. 


autoheal 模式 参考 配置 如 下 : 


[ 
{ 
rabbit, [ 
(cluster partition handling, autoheal) 


] 
Ts 
对 于 pause-minority 模式 ,关闭 节点 的 状态 是 在 网 络 故障 时 ,也 就 是 判定 出 net. tick timeout 
之 时 ， 会 关闭 “少数 派 ” 分 区 中 的 节点 ， 等 待 网 络 恢复 之 后 ， 即 判定 出 网 络 分 区 之 后 ， 启 动 关 
闭 的 节点 来 从 网 络 分 区 中 恢复 。autoheal 模式 在 判定 出 net tick timeout 之 时 不 做 动作 ， 要 等 到 
网 络 恢复 之 时 ， 在 判定 出 网 络 分 区 之 后 才 会 有 相应 的 动作 ， 即 重启 非 获 胜 分 区 中 的 节点 。 
注意 要 点 : 


在 autoheal 模式 下 ， 如 果 集 群 中 有 节点 处 于 非 运行 状态 ， 那 么 当 发 生 网 络 分 区 的 时 候 ， 将 
不 会 有 任何 自动 处 理 的 动作 。 源 码 中 对 此 有 相关 说 明 : To keep things simple, we assume all nodes 


are up. We don t start unless all nodes are up, and if a node goes down we abandon the whole process. 


10.6.4 ”挑选 哪 种 模式 


有 一 点 必须 要 清楚 ， 人 允许 RabbitMQ 能 够 自动 处 理 网 络 分 区 并 不 一 定 会 有 正面 的 成 效 ， 也 
有 可 能 会 带 来 更 多 的 问题 。 网 络 分 区 会 导致 RabbitMQ 集群 产生 众多 的 问题 ， 需 要 对 遇 到 的 问 
题 做 出 一 定 的 选择 。 就 像 本 章 开 篇 所 说 的 ， 如 果 置 RabbitMQ 于 一 个 不 可 靠 的 网 络 环境 下 ， 需 
要 使 用 Federation 或 者 Shovel。 就 算 从 网 络 分 区 中 恢复 了 之 后 ， 也 要 谨防 发 生 二 次 网 络 分 区 。 
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每 种 模式 都 有 自身 的 优 缺 点 ， 没 有 哪 种 模式 是 万 无 一 失 的 ， 希 望 根据 实际 情形 做 出 相应 的 
选择 ， 下 面 简要 概论 以 下 4 个 模式 。 


仿 ignore 模式 : 发 生 网 络 分 区 时 ， 不 做 任何 动作 ， 需 要 人 工 介入 。 


* pause-minority 模式 : 对 于 对 等 分 区 的 处 理 不 够 优雅 ， 可 能 会 关闭 所 有 的 节点 。 一 般 情 
况 下 ， 可 应 用 于 非 跨 机 架 、 奇 数 节点 数 的 集群 中 。 

+ pause-if-all-down 模式 : 对 于 受信 节点 的 选择 尤为 考究 ， 尤 其 是 在 集群 中 所 有 节点 硬件 
配置 相同 的 情况 下 。 此 种 模式 可 以 处 理 对 等 分 区 的 情形 。 


+ autoheal 模式 : 可 以 处 于 各 个 情形 下 的 网 络 分 区 。 但 是 如 果 集 群 中 有 节点 处 于 非 运行 状 
态 ， 则 此 种 模式 会 失效 。 


10.7 案例 : 多 分 区 情形 


为 了 简化 说 明 ， 本 章 前 面 的 讨论 大 多 基于 分 成 两 个 分 区 的 情形 。 在 实际 应 用 中 ， 如 果 集 群 
中 节点 所 在 物理 机 是 多 网 卡 ， 当 某 节点 网 卡 发 生 故 障 就 有 可 能 会 发 生 多 个 分 区 的 情形 。 


案例 : 集群 中 有 6 个 节点 ， 分 别 为 node1、node2、node3、node4、node5 和 node6， 每 个 节 
点 所 在 物理 机 都 是 4 网 卡 (网 卡 名 称 分 别 为 eth0、ethl1、eth2 和 eth3) 配置 ， 并 采用 bindo’ 的 
绑 定 模式 。 当 node6 的 eth0 故障 之 后 ， 整 个 集群 演变 成 为 了 6 个 分 区 ， 即 每 个 节点 为 一 个 独立 
的 分 区 。 


网 络 分 区 之 前 ， 集 群 中 的 各 个 节点 相互 通信 ， 如 图 10-4 所 示 。 为 了 简要 说 明 ， 合 理 先 只 展 
示 nodel、node3 和 node6 节点 。 如 图 10-5 所 示 ， 三 个 节点 两 两 互 连 。 


”关于 多 网 卡 的 bind 模式 也 是 一 门 大 学 问 ， 三 言 两 语 难以 阐述 其 细节 ， 有 兴趣 的 读者 可 以 自行 翻阅 相关 资料 ， 本 章 只 阐述 其 引 
起 多 网 络 分 区 的 细节 。 
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图 10-5 ”节点 两 两 互 连 


Æ node6 的 网 被 关闭 之 后 ， 对 于 bondo 的 网 卡 绑 定 模式 ， 交换机 无 法 感知 eth0 网 卡 的 故障 , 但 
是 node6 节点 能 够 感知 本 地 eth0 的 故障 。 对 于 node3 节点 而 言 , 其 与 node6 的 eth0 网 卡 建立 的 长 连 
接 没 有 被 关闭 ，node3 会 向 node6 重 试 发 送 数 据 (TCP retransmission)， 但 是 node6 节点 无 法 回应 。 
除非 主动 关闭 或 者 等 待 长 连接 超时 (默认 为 7200s， 即 2 小 时 )， 此 条 链 路 才 会 被 关闭 。 


X node6 网 卡 关 闭 之 后 ，nodel、node3 和 node6 有 如 下 变化 。 
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第 一 步 ， 与 node6 上 eth0 相关 的 链 路 不 通 ，node3 此 时 需要 等 待 net ticktime 的 超时 。 
节点 node3 中 的 相关 日 志 如 下 : 


rabbit on node 'rabbit@node6' down 
node 'rabbit8node6' down: net tick timeout 


第 二 步 ， 待 超时 之 后 ， 主 动 关闭 连接 。 节 点 node3 的 相关 日 志 如 下 : 


node 'rabbit8node6' down: connection closed 


与 此 同时 Erlang 虚拟 机 尝试 让 node3 与 node6 重新 建立 连接 ， 由 于 node6 上 的 其 他 网 卡 正 
常 ， 最 后 node3 和 node6 可 以 建立 。 


node 'rabbit68node6' up 


第 三 步 ， 判 定 node3 和 node6 之 间 产 生 了 网 络 分 区 。 


Mnesia ('rabbit@node3'): ** ERROR ** mnesia event got (inconsistent database, 
running partitioned network, 'rabbit8node6')] 


到 这 里 还 没有 结束 ,网络 分 区 会 继续 演变 。 此 时 node3 和 nodel 还 处 于 连通 状态 , 同样 node6 
和 nodel 也 处 于 连通 状态 。 进 一 步 查 看 node3 的 日 志 : 


Partial partition detected: 

* We saw DOWN from rabbitG8node6 

* We can still see rabbit@nodel which can see rabbit8node6 
We will therefore intentionally disconnect from rabbit@nodel 


上 面 这 段 日 志 是 说 :node3 和 node6 之 间 发 生 了 网 络 分 区 , 但 是 node3 又 发 现 nodel 和 node6 
内 部 通信 还 没有 断 ， 此 时 认为 nodel 和 node6 处 于 同一 个 分 区 ， 那 么 node3 就 准备 主动 关闭 与 
nodel 之 间 的 内 部 通信 ， 最 后 node3 和 nodel 之 间 也 发 生 了 分 区 。 


与 此 同时 ， 对 于 节点 node6 而 言 ，nodel 和 node3 还 处 于 同一 个 分 区 ， 那 么 node6 也 要 将 
nodel H F node6 本 身 的 分 区 之 外 。 最 后 nodel. node3 与 node6 都 处 于 不 同 的 网 络 分 区 。 


到 这 里 还 是 没有 结束 ， 继 续 查 看 nodel 中 的 日 志 可 以 发 现 : 


-ERROR REPORT---- 16-0ct-2017::14:20:54 === 

Partial partition detected: 

* We saw DOWN from rabbit8node3 

* We can still see rabbit8node4 which can see rabbit8node3 
We will therefore intentionally disconnect from rabbitnode4 


-INFO REPORT---- 16- Oct -2017::14:20:55 === 
rabbit on node 'rabbit8node4' down 
-INFO REPORT---- 16- Oct -2017::14:20:55 --- 


e 295 è 





RabbitMQ 实战 指南 


node 'rabbit8node4' down: disconnect 

-INFO REPORT---- 16- Oct -2017::14:20:55 === 

node 'rabbit8node4' up 

-ERROR REPORT---- 16- Oct -2017::14:20:55 --- 
Mnesia('rabbit8nodel'): ** ERROR ** mnesia event got 
(inconsistent database, running partitioned network, 'rabbit8node4 


可 以 看 到 nodel 此 时 察觉 到 node4 与 node3 之 间 还 有 内 部 通信 交换 , 那么 就 会 主动 将 node4 
剥离 出 自身 的 分 区 。 如 此 演变 ， 最 终 nodel. node2. node3. node4. node5 和 node6 处 于 6 个 
不 同 的 分 区 。 


在 此 种 故障 下 ， 如 果 选 择 自动 处 理 网 络 分 区 会 有 什么 不 同 的 效果 呢 ? 对 于 
pause if all down 模式 而 言 ， 如 果 挑 选 1 个 节点 作为 受信 节点 ， 那 么 会 重启 剩余 的 $ 个 节点 以 
作 恢 复 。 对 于 autoheal 同样 如 此 ， 且 查看 日 志 可 以 发 现 ，autoheal 会 等 网 络 分 区 判定 之 后 罗列 出 
所 有 分 区 信息 ， 然 后 再 重启 非 获 胜 分 区 中 的 节点 ， 同 样 需要 重启 5 个 节点 。 然 而 对 于 
pause minority 的 配置 而 言 ， 对 此 种 情形 的 处 理 要 优雅 很 多 ， 当 有 节点 检测 到 net tick timeout 
之 后 会 自行 重启 当前 节点 ， 这 样 就 阻止 了 网 络 分 区 进一步 演变 ， 且 处 理 效率 最 高 。 


10.8 小 结 


本 章 主要 阐述 了 网 络 分 区 的 意义 ， 如 何 查 看 和 处 理 网 络 分 区 及 网 络 分 区 所 带 来 的 影响 。 虽 
然 前 面 的 内 容 没 有 提 及 ， 但 是 对 于 网 络 分 区 的 监控 也 尤为 重要 。 首 先 ， 若 发 生 网 络 分 区 ， 客 户 
端 有 可 能 会 报错 ， 相 关 的 日 志 检测 机 制 可 以 示警 ， 但 是 此 时 无 法 确定 发 生 了 网 络 分 区 ， 需 要 进 
一 步 分 析 ， 从 而 影响 处 理 网 络 分 区 的 实效 性 。 当 然 也 可 以 通过 人 工 的 方式 查看 Web 管理 界面 或 
者 使 用 rabbitmqctl cluster status 检测 到 网 络 分 区 的 发 生 ， 但 是 这 种 非 自 动 化 的 手段 
远 非 长 久之 计 。 真 正 可 取 的 有 两 种 方式 : 第 一 种 是 监测 /api/nodes 这 个 HTTP API 接口 所 返 
回 的 JSON 字符 串 中 partitions 项 中 是 否 有 节点 信息 ; 第 二 种 是 监测 RabbitMQ 的 服务 日 志 
是 否 有 Mnesia('rabbit@nodel'): ** ERROR ** mnesia event got (inconsistent 
database, running partitioned network，'rabbit@node2' } 类 似 的 日 志 ， 可 以 参考 
7.2 节 。 这 两 种 方式 都 可 以 做 成 自动 化 的 应 用 。 附录 C 中 展示 了 一 张 有 关 网 络 分 区 的 思维 导 图 ， 
供 读 者 参考 。 
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有 关 RabbitMQ 的 概念 介绍 、 结 构 模 型 、 客 户 端 应 用 等 可 以 看 作 基 础 篇 有关 RabbitMQ 的 
管理 、 配 置 、 运 维 等 可 以 看 作 中 级 篇 ,而 RabbitMQ 的 原理 及 网 络 分 区 的 介绍 可 以 看 作 高 级 篇 ， 
所 陈述 的 都 是 RabbitMQ 在 运行 时 使 用 到 的 一 些 本 体 知识 。 而 本 章 内 容 作为 一 个 拾遗 扩展 ， 主 
要 介绍 RabbitMQ 的 消息 追踪 和 服务 端 入 站 连接 的 负载 均衡 。 
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111 消息 追踪 


在 使 用 任何 消息 中 间 件 的 过 程 中 , 难免 会 出 现 消 息 异 常 丢 失 的 情况 。 对 于 RabbitMQ 而 言 ， 
可 能 是 生产 者 与 Broker 断 开 了 连接 并 且 也 没有 任何 重 试 机 制 ; 也 可 能 是 消费 者 在 处 理 消息 时 发 
生 了 异常 ， 不 过 却 提 前 进行 了 ack; 甚至 是 交换 器 并 没有 与 任何 队列 进行 绑 定 ， 生 产 者 感知 不 
到 或 者 没有 采取 相应 的 措施 ， 另 外 RabbitMQ 本 身 的 集群 策略 也 可 能 导致 消息 的 丢失 。 这 个 时 
候 就 需要 有 一 个 良好 的 机 制 来 跟踪 记录 消息 的 投递 过 程 ， 以 此 协助 开发 或 者 运 维 人 员 快 速 地 定 
位 问题 。 


11.1.1 Firehose 


在 RabbitMQ 中 可 以 使 用 Firehose 功能 来 实现 消息 追踪 ,Firehose 可 以 记录 每 一 次 发 送 或 者 
消费 消息 的 记录 ， 方 便 RabbitMQ 的 使 用 者 进行 调试 、 排 错 等 。 


Firehose 的 原理 是 将 生产 者 投递 给 RabbitMQ 的 消息 ， 或 者 RabbitMQ 投递 给 消费 者 的 消息 按 
照 指定 的 格式 发 送 到 默认 的 交换 器 上 。 这 个 默认 的 交换 器 的 名 称 为 amq.rabbitmq.trace, 它 是 
一 个 topic 类 型 的 交换 器 。 发送 到 这 个 交换 器 上 的 消息 的 路 由 键 为 Publish. {exchangename} 和 
deliver. {queuename}。 其 中 exchangename 和 queuename 为 交换 器 和 队列 的 名 称 ， 分 别 对 
应 生产 者 投递 到 交换 器 的 消息 和 消费 者 从 队列 中 获取 的 消息 。 

开启 Firehose 命令 : rabbitmqctl trace on [-p vhost]。 其 中 [-p vhost] 是 可 选 
参数 , 用 来 指定 虚拟 主机 vhost。 对 应 的 关闭 命令 为 rabbitmqctltrace off [-p vhost]. 
Firehose 默认 情况 下 处 于 关闭 状态 ， 并 且 Firehose 的 状态 也 是 非 持 久 化 的 , 会 在 RabbitMQ 服务 
重启 的 时 候 还 原 成 默认 的 状态 。Firehose 开启 之 后 多 少 会 影响 RabbitMQ 整体 服务 的 性 能 ， 因 为 
它 会 引起 额外 的 消息 生成 、 路 由 和 存储 。 

下 面 我 们 举例 说 明 Firehose 的 用 法 。 需 要 做 一 下 准备 工作 ， 确 保 Firehose 处 于 开启 状态 ， 
创建 7 个 队列 : queue. queue.another. queuel. queue2. queue3. queue4 和 queue5。 之 后 再 创 
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建 2 个 交换 器 exchange 和 exchange.another， 分 别 通过 路 由 键 rk 和 tk.another 与 queue 和 
queue.another 进行 绑 定 。 最 后 将 amq. rabbitmq.trace 这 个 关键 的 交换 器 与 queuel、queue2、 
queue3、queue4 和 queue5 绑 定 ， 详 细 示 意图 可 以 参考 图 11-1。 


queue 


i FE 


queue. another 






exchange. 


图 11-1 结构 示意 图 


分 别 用 客户 端 向 exchange 和 exchange.another 中 发 送 一 条 消息 “trace test payload. ”, 然后 再 
用 客户 端 消费 队列 queue 和 queue.another 中 的 消息 。 


此 时 queuel 中 有 2 条 消息 , queue2 中 有 2 条 消息 ,queue3 中 有 4 条 消息 ,而 queue4 和 queue5 
中 只 有 1 条 消息 ,在 向 exchange 发 送 1 条 消息 后 ,amq .rabbitmq.trace 分 别 向 queuel、queue3 
和 queue4 发 送 1 条 内 部 封装 的 消息 。 同 样 ， 在 向 exchange.another 中 发 送 1 条 消息 之 后 ， 对 应 
的 队列 queuel 和 queue3 中 会 多 1 条 消息 。 消 费 队 列 queue 的 时 候 ，queue2、queue3 和 queue5 
中 会 多 1 条 消息 ; 消费 队列 queue.another 的 时 候 ，queue2 和 queue3 会 多 1 条 消息 。“publish.#” 
匹配 发 送 到 所 有 交换 器 的 消息 , “deliver#” 匹 配 消费 所 有 队列 的 消息 , 而 “#” 则 包含 了 “publish.#” 
和 “deliver.#”。 


e299。 


RabbitMQ 实战 指南 


在 Firehose 开启 状态 下 ， 当 有 客户 端 发 送 或 者 消费 消息 时 ，Firehose 会 自动 封装 相应 的 消 
息 体 ， 并 添加 详细 的 headers 属性 。 对 于 前 面 的 将 “trace test payload.” 这 条 消息 发 送 到 交换 


器 exchange 来 说 ，Firehore 会 将 其 封装 成 如 图 11-2 中 所 示 的 内 容 。 


Exchange 
Routing Key 
Redelivered 

Properties 


Payload 
19 bytes 
Encoding: string 


amq.rabbitmq.trace 
publish exchange 


e 


headers: exchange name: exchange 


routing keys: 
properties: 


node 


vhost: 


connection 


rk 


priority: 0 
delivery mode: 2 
content, type: text/plain 


: rabbitnode1 
i 
:192.168.0.9:64150->192.168.0.2:5672 


channel: 
user: 


routed_queues 


trace test payload. 


11-2 





封装 消息 


在 消费 queue 时 ， 会 将 这 条 消息 封装 成 如 图 11-3 中 所 示 的 内 容 : 


amq.rabbitmq.trace 


deliver.queue 


e 


headers: exchange name 


Payload 
19 bytes | trace test payload. 


Encoding: string 
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: exchange 


routing. keys: rk 


priority: 0 


delivery mode: 2 


content, type: text/plain 


: rabbitGnode1 
:0 


> 


:192.168.0.9:64150~>192.169.0.2:5672 
:1 
: root 





11-3. 封装 消息 GH queue 时 ) 


$8 112€ ”RabbitMQ 扩展 


headers 中 的 exchange name 表示 发 送 此 条 消息 的 交换 器 ; routing keys 表示 与 
exchange name 对 应 的 路 由 键 列表 ; properties 表示 消息 本 身 的 属性 ， 比 如 
delivery_mode 设置 为 2 表示 消息 需要 持久 化 处 理 。 


11.1.2 rabbitmq tracing 插件 





rabbitmq tracing 插件 相当 于 Firehose 的 GUI 版 本 ， 它 同样 能 跟踪 RabbitMQ 中 消息 
的 流入 流出 情况 。rabbitmq tracing 插件 同样 会 对 流入 流出 的 消息 进行 封装 ， 然 后 将 封装 
后 的 消息 日 志 存 入 相应 的 trace 文件 之 中 。 

可 以 使 用 rabbitmq-plugins enable rabbitmq tracing 命令 来 启动 rabbitmq_ 
tracing 插件 : 


[root@nodel ~]# rabbitmq-plugins enable rabbitmq tracing 

The following plugins have been enabled: 

rabbitmq tracing 

Applying plugin configuration to rabbit8node3... started 1 plugin. 


对 应 的 关闭 插件 的 命令 是 rabbitmq-plugins disable rabbitmq tracing. 

在 Web 管理 界面 “Admin” 右 侧 原 本 只 有 “Users”“Virtual Hosts" fI “Policies” 3X^^ — 
Tab 项 ， 在 添加 rabbitmq tracing 插件 之 后 ， 会 多 出 “Tracing” 这 一 项 内 容 ， 如 图 11-4 
所 示 。 


Users 


Virtual Hosts 


Policies 


图 11-4 “Tracing” 项 





可 以 在 此 Tab 项 中 添加 相应 的 trace， 如 图 11-5 所 示 。 
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w All traces 


Currently running traces 


... no traces running ... 


* Addanew trace 


Name: | 


mmc [hn 


Max payload bytes: (?) | 


pattern: |* EU j 
Examples: #, publish.&, deliver. #.amq.direct, #.myqueue 





Æ 11-5 在 Tab 项 中 添加 trace 


在 添加 完 trace 之 后 ， 会 根据 匹配 的 规则 将 相应 的 消息 日 志 输出 到 对 应 的 trace 文件 之 中 ， 
文件 的 默认 路 径 为 /var/tmp/rabbitmq-tracing。 可 以 在 页 面 中 直接 点 击 “Trace log files" 
下 面 的 列表 直接 查看 对 应 的 日 志文 件 。 


如 图 11-6 所 示 ， 我 们 添加 了 两 个 trace 任务 。 


Currently running traces 


| Name | pattem | 










11-6 添加 任务 
与 其 相对 应 的 trace 文件 如 图 11-7 所 示 。 


11-7. “对 应 的 trace 文件 
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再 添加 完 相应 的 trace 任务 之 后 ， 会 发 现 多 了 两 个 队列 ， 如 图 11-8 所 示 。 


Overview 
Name Node 
amq.gen-MoyvSKQau9udetldlUdQZw nodel | 





就 以 第 一 个 队列 amq.gen-MoyvSKQau9udetldIUdQZw 而 言 ， 其 所 绑 定 的 交换 器 就 是 
amq.rabbitmq.trace， 如 图 11-9 所 示 。 


Queue amq.gen-MoyvSKQau9udetl4lUdQZw 
> Overview 


v Consumers 


Channel Consumer tag | Ack required Exclusive 
‘<rabbit@node1.3.3512.0> (1) ,amqctag-UBDFyEwvWsbbY2UIQXXdKA ho 


* Bindings 


From | Routing key Arguments | 
[Re 


| amq.rabbitmq.trace | 


y 


Æ 11-9 amq.gen-MoyvSKQau9udetl4IUdQZw 队列 


由 此 可 以 看 出 整个 rabbitmq tracing 插件 和 Firehose 在 实现 上 如 出 一 略 ， 只 不 过 
rabbitmq tracing 插件 比 Firehose 多 了 一 层 GUI 的 包装 ， 更 容易 使 用 和 管理 。 


再 来 补充 说 明 图 11-5 中 Name. Format. Max payload bytes, Pattern 的 具体 含义 。 
Name， 顾 名 思 义 ， 就 是 为 即将 创建 的 trace 任务 取 个 名 称 。 


Format 表示 输出 的 消息 日 志 格式 ,有 Text 和 JSON 两 种 , Text 格式 的 日 志方 便 人 类 阅读 ， 
JSON 的 格式 方便 程序 解析 。 
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Text 格式 的 消息 日 志 参 考 如 下 : 


2017-10-24 9:37:04:412: Message published 





Node: rabbit8nodel 
Connection: «rabbit8nodel.3.3552.0» 
Virtual host: / 


User: root 
Channel: 1 
Exchange: exchange 


Routing keys: [««"rk"»»] 

Routed queues: [««"queue"»»5] 

Properties: [(««"delivery mode"»»,signedint,1),[(««"headers"»»,table, []]] 
Payload: 

trace test payload. 


JSON 格式 的 消息 日 志 参 考 如 下 : 


( 
"timestamp": "2017-10-24 9:37:04:412", 
"type": "published", 


"node": "rabbitQnodel", 

"Connection": "«rabbitG8nodel.3.3552.0»", 

"uhost"s "mj. 

"usgar"; "root", 

"Channel": 1, 

"exchange": "exchange", 

"queue": "none", 

"routed queues": [ "queue" ], 

"houting keys": [ "Ek" ], 

"properties"; ( "delivery mode": 1, "headers": () ], 


"payload": "dHJhY2UgdGVzdCBwYXlsb2FkLg--" 
) 


JSON 格式 的 payload( 消 息 体 ) 默 认 会 采用 Base64 进行 编码 , 如 上 面 的 “trace test payload." 
会 被 编码 成 “dHJhY2UgdGVzdCBwYXlsb2FkLeg==”。 


Max payload bytes 表示 每 条 消息 的 最 大 限制 ， 单 位 为 B。 比 如 设置 了 此 值 为 0， 那 
么 当 有 超过 10B 的 消息 经 过 RabbitMQ 流转 时 ， 在 记录 到 trace 文件 时 会 被 截断 。 如 上 Text 日 
志 格 式 中 “trace test payload.” 会 被 截断 成 “trace test". 


Pattern 用 来 设置 匹配 的 模式 ， 和 Firehose 的 类 似 。 如 “# ”匹配 所 有 消息 流入 流出 的 情 
况 , 即 当 有 客户 端 生产 消息 或 者 消费 消息 的 时 候 , 会 把 相应 的 消息 日 志 都 记录 下 来 , publish." 
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匹配 所 有 消息 流入 的 情况 ;“deliver#” 匹 配 所 有 消息 流出 的 情况 。 


11.1.3. RB: 可 靠 性 检测 


由 7.1 节 中 的 介绍 可 知 ， 当 生产 者 将 消息 发 送 到 交换 器 时 ， 实 际 上 是 由 生产 者 所 连接 的 信 
道 将 消息 上 的 路 由 键 同 交换 器 的 绑 定 列表 比较 ， 之 后 再 路 由 消息 到 相应 的 队列 进程 中 。 那 么 在 
信道 比 对 完 绑 定 列表 之 后 ， 将 消息 路 由 到 队列 并 且 保 存 的 过 程 中 ， 是 否 会 由 于 RabbitMQ 的 内 
部 缺陷 而 引起 偶然 性 的 消息 丢失 ? 如 果 你 对 此 也 有 同样 的 疑问 ， 就 可 以 使 用 RabbitMQ 的 消息 
追踪 机 制 来 验证 这 一 情况 。 大 致 思路 : 一 个 交换 器 通过 同一 个 路 由 键 绑 定 多 个 队列 ， 生 产 者 客 
户 端 采用 同一 个 路 由 键 发 送 消息 到 这 个 交换 器 中 ， 检 测 其 所 绑 定 的 队列 中 是 否 有 消息 丢失 。 


1. 具体 测试 案例 准备 细节 

(1) 在 RabbitMQ 集群 开启 rabbitmq tracing 插件 。 

(2) 创建 1 个 交换 器 exchange 和 3 个 队列 : queue1、queue2、queue3， 都 用 同一 个 路 由 键 
“rk” HITRE. 

(3) 创建 3 个 trace: tracel, trace2, trace3 分 别 , 采用 “#.queuel”、“#.queue2”、“#.queue3” 
的 Pattern 来 追踪 从 队列 queuel, queue2, queue3 中 消费 的 消息 。 


(4) 创建 1 个 trace: trace publish 采用 publish.exchange 的 Pattern 来 追踪 流入 交 
换 器 exchange 的 消息 。 


2. 验证 过 程 


第 一 步 ， 开 启 1 个 生产 者 线程 ， 然 后 持续 发 送 消息 至 交换 器 exchange。 消 息 的 格式 为 “ 当 
前 时 间 戳 + 自 增 计数 ”如 “1506067447530-726” 这 样 在 检索 到 相应 数据 丢失 时 可 以 快速 在 trace 
日 志 中 找到 大 致 的 地 方 。 注 意 设置 mandatory 参数 ， 防 止 消息 路 由 不 到 对 应 的 队列 而 造成 对 
消息 丢失 的 误 判 。 在 消息 发 送 之 前 需要 将 消息 以 [msg, QUEUE_NUM] 的 形式 存 入 一 个 全 局 的 
msgMap 中 ， 用 来 在 消费 端 做 数据 验证 。 这 里 的 QUEUE NUM 为 3， 对 应 创建 的 3 个 队列 。 
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对 应 的 内 部 生产 者 线程 类 的 细节 如 代码 清单 11-1 所 示 。 





private static HashMap<String Integer» msgMap = new HashMap«String, Integer»(); 

//1og2disk 是 用 来 记录 测试 程序 的 log 日 志 的 ， 当 然 可 以 使 用 1og4j 或 Logback 等 替代 

private static BlockingQueue«String» log2disk = new 
LinkedBlockingQueue«String»?(); 


public static class ProducerThread implements Runnable ( 
private Connection connection; 
public ProducerThread (Connection connection) ( 
this.connection - connection; 
} 
public void run() ( 
try ( 
Channel channel = connection.createChannel(); 
channel.addReturnListener(new ReturnListener() ( 
public void handleReturn(int replyCode, String replyText, 
String exchange, 
String routingKey, AMQP.BasicProperties properties, 
byte[] body) throws IOException { 
String errorInfo = "Basic.Return: " + new String (body)-*"Mn"; 
try ( 
log2disk.put (errorInfo); 
) catch (InterruptedException e) ( 
e.printStackTrace(); 
} 
System.out.println(errorInfo); 
) 
}); 
int count-0; 
while (true) ( 
String message = new Date().getTime() + "-" + count-t*; 
synchronized (msgMap) { 
msgMap.put (message, QUEUE NUM); 
) 
channel.basicPublish(exchange, routingKey, true, 
MessageProperties.PERSISTENT TEXT PLAIN, 
message.getBytes()); 
txy f 
//QPS=10， 这 里 的 QPS 限定 可 以 自 适应 调节 
/ /当然 ops 不 宜 过 高 ， 防 止 队列 堆积 严重 
TimeUnit.MILLISECONDS.sleep(100); 
) catch (InterruptedException e) { 
e.printStackTrace(); 
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) 

) catch (IOException e) ( 
e.printStackTrace(); 

} 


} 
注意 代码 里 的 存储 消息 的 动作 一 定 要 在 发 送 消息 之 前 ， 如 果 在 代码 清单 11-1 中 调换 顺序 ， 


生产 者 线程 在 发 送 完 消息 之 后 ， 并 抢占 到 msgMap 的 对 象 锁 之 前 ， 消 费 者 就 有 可 能 消费 到 相应 
的 数据 ， 此 时 msgMap 中 并 没有 相应 的 消息 ， 这 样 会 误 报错 误 ， 如 代码 清单 11-2 所 示 。 





// error demo. don't do this.... 
channel.basicPublish(exchange, routingKey, true, 
MessageProperties.PERSISTENT TEXT PLAIN, 

message.getBytes()); 
synchronized (msgMap)(í 
msgMap.put (message, QUEUE NUM); 
} 


第 二 步 ， 开 启 3 个 消费 者 线程 分 别 消费 队列 queuel, queue2. queues 的 消息 ， 从 存储 的 
msgMap 中 寻找 是 否 有 相应 的 消息 。 如 果 有 ， 则 将 消息 对 应 的 value 计数 减 1， 如 果 value 计数 
为 0， 则 从 Map 中 删除 此 条 消息 ;如 果 没 有 找到 这 条 消息 则 报错 。 对 应 的 内 部 消费 线程 类 的 实 
现 细节 如 代码 清单 11-3 所 示 。 





public static class ConsumerThread implements Runnable ( 
private Connection connection; 
private String queue; 
public ConsumerThread(Connection connection, String queue) ( 
this.connection = connection; 
this.queue - queue; 
} 
public void run() { 
try { 
final Channel channel = connection.createChannel(); 
channel.basicQos(64); 
channel.basicConsume(this.queue, new DefaultConsumer (channel) { 
public void handleDelivery(String consumerTag, 
Envelope envelope, 
AMQP.BasicProperties properties, 
byte[] body) throws IOException( 
String msg = new String (body); 
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synchronized (msgMap) ( 
if (msgMap.containsKey (msg)) ( 
int count = msgMap.get (msg); 
count--; 
if (count » O0) ( 
msgMap.put (msg, count); 
Jelse { 
msgMap.remove (msg) ; 
} 
) 
else( 
String errorInfo = "unknown msg : " + msg-t"Mn"; 
try 1 
log2disk.put (errorInfo); 
System.out.println(errorInfo); 
) catch (InterruptedException e) ( 
e.printStackTrace(); 
} 
} 
} 
channel.basicAck(envelope.getDeliveryTag(), false); 
} 
}); 
} catch (IOException e) { 
e.printStackTrace(); 


) 


) 


第 三 步 ， 开 启 一 个 检测 进程 ， 每 隔 10 分 钟 检测 msgMap 中 的 数据 。 由 前 面 的 描述 可 知 
msgMap 中 的 键 就 是 消息 ， 而 消息 中 有 时 间 戳 的 信息 ， 那 么 可 以 将 这 个 时 间 恰 与 当前 的 时 间 戳 
进行 对 比 ， 如 果 发 现 差 值 超过 10 分 钟 ， 这 说 明 可 能 有 消息 丢失 。 这 个 结论 的 前 提 是 队列 中 基本 
没有 堆积 ， 并 且 前 面 的 生产 和 消费 代码 同时 运行 时 可 以 保证 消费 消息 的 速度 不 会 低 于 生产 消息 
的 速度 。 对 应 的 检测 程序 如 代码 清单 11-4 所 示 。 


vi 





public static class DetectThread implements Runnable { 
public void run() ( 
while (true) ( 
try ( 
TimeUnit.MINUTES.sleep(10); 
) catch (InterruptedException e) ( 
e.printStackTrace(); 
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synchronized (msgMap) í( 
if (msgMap.size() > 0) ( 
long now = new Date().getTime(); 
for (Map.Entry«String, Integer» entry : msgMap.entrySet()) { 
String msg = entry.getKey(); 
if (now - parseTime(msg) >= 10 * 60 * 1000) ( 
String findLossInfo - "We find loss msg: 
" 4 msg + " ,now the time 
is: " # now + ", and this msg still has "+ 
entry.getValue()-*" missed"+"\n"; 
try ( 
log2disk.put(findLossInfo); 
System.out.println(findLossInfo); 
msgMap.remove (msg); 
) catch (InterruptedException e) { 
e.printStackTrace(); 


) 


} 


public static Long parseTime (String msg) { 
int index = msg.indexOf('-'); 
String timeStr = msg.substring(0, index); 
Long time = Long.parseLong (timeStr); 
return time; 


} 


如 果 检 测 到 msgMap 中 有 消息 超过 10 分 钟 没有 被 处 理 , 此 时 还 不 能 证 明 有 数据 丢失 , 这 里 
就 需要 用 到 了 trace。 如 果 看 到 [msg, count] 这 条 数据 中 有 以 下 情况 : 


* 考虑 count=3 的 情况 。 需 要 检索 trace 文件 trace publish.log 来 进一步 验证 。 如 果 
trace publish.log 中 没有 搜索 到 相应 的 消息 则 说 明 消息 未 发 生 到 交换 器 exchange "P; 如 
果 trace_publish.log 中 检索 到 相应 的 消息 ， 那 么 可 以 进一步 检索 tracel.log、trace2.log 和 
trace3.log 来 进行 验证 ， 如 果 这 3 个 trace 文件 中 不 是 全 部 都 有 此 条 消息 ， 则 验证 了 本 节 
开头 所 述 的 消息 丢失 现象 。 


分 考虑 0<count<3 的 情况 。 需 要 检索 tracel.log、trace2.log 和 trace3.log 来 进一步 验证 ， 如 果 
这 3 个 trace 文件 中 不 是 全 部 都 有 此 条 消息 ， 则 验证 了 本 节 开 篇 所 述 的 消息 丢失 问题 。 
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€ 考虑 count=0 的 情况 。 说 明 检 测 程序 异常 ， 可 以 忽略 。 


这 里 补充 主线 程 的 部 分 代码 如 代码 清单 11-5 所 示 。 注 意 这 里 有 个 PrintLogThread 的 线 
FE, 此 线程 主要 用 来 读 取 10g2disk 这 个 Blockingoueue 中 所 存储 的 异常 日 志 然 后 进行 存盘 
处 理 ， 当 然 这 个 功能 完全 可 以 用 log4j 或 者 logback 等 第 三 方 日 志 工具 替代 ， 原 理 比 较 简 单 ， 在 
此 不 做 代码 展示 。 


RERA 


Connection connection = connectionFactory.newConnection(); 

PrintLogThread printLogThread = new PrintLogThread(logFileAddr); 
ProducerThread producerThread - new ProducerThread (connection); 
ConsumerThread consumerThreadl = new ConsumerThread(connection, "queuel"); 
ConsumerThread consumerThread2 = new ConsumerThread (connection, "queue2"); 
ConsumerThread consumerThread3 = new ConsumerThread(connection, "queue3"); 
DetectThread detectThread = new DetectThread(); 
System.out.println("starting check msg loss...."); 

ExecutorService executorService - Executors.newCachedThreadPool(); 
executorService.submit (printLogThread); 

executorService.submit (producerThread); 

executorService.submit (consumerThreadl); 

executorService.submit (consumerThread2); 

executorService.submit (consumerThread3); 

executorService.submit (detectThread); 

executorService.shutdown(); 





112 负载 均 稀 


面 对 大 量 业务 访问 、 高 并 发 请 求 ， 可 以 使 用 高 性 能 的 服务 器 来 提升 RabbitMQ 服务 的 负载 
能 力 。 当 单机 容量 达到 极限 时 ， 可 以 采取 集群 的 策略 来 对 负载 能 力 做 进一步 的 提升 ， 但 这 里 还 
存在 一 个 负载 不 均衡 的 问题 。 试 想 如 果 一 个 集群 中 有 3 个 节点 ， 那 么 所 有 的 客户 端 都 与 其 中 的 
单个 节点 nodel 建立 TCP 连接 ， 那 么 nodel 的 网 络 负载 必然 会 大 大 增加 而 显得 难以 承受 ， 其 他 
节点 又 由 于 没有 那么 多 的 负载 而 造成 硬件 资源 的 浪费 ， 所 以 负载 均衡 显得 尤为 重要 。 


对 于 RabbitMQ 而 言 ， 客 户 端 与 集群 建立 的 TCP 连接 不 是 与 集群 中 所 有 的 节点 建立 连接 ， 
而 是 挑选 其 中 一 个 节点 建立 连接 。 如 图 11-10 所 示 ， 在 引入 了 负载 均衡 之 后 ， 各 个 客户 端的 连 
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接 可 以 分 摊 到 集群 的 各 个 节点 之 中 ， 进 而 避免 了 前 面 所 讨论 的 缺陷 。 


RabbitMQ Cluster 





11-10 引入 负载 均衡 


负载 均衡 (Load balance) 是 一 种 计算 机 网 络 技术 ， 用 于 在 多 个 计算 机 (计算 机 集群 )、 网 
络 连接 、CPU、 磁 盘 驱 动 器 或 其 他 资源 中 分 配 负载 ， 以 达到 最 佳 资源 使 用 、 最 大 化 吞吐 率 、 最 
小 响应 时 间 及 避免 过 载 的 目的 。 使 用 带 有 负载 均衡 的 多 个 服务 器 组 件 ， 取 代 单 一 的 组 件 ， 可 以 
通过 元 余 提 高 可 靠 性 。 


负载 均衡 通常 分 为 软件 负载 均衡 和 硬件 负载 均衡 两 种 。 


软件 负载 均衡 是 指 在 一 个 或 者 多 个 交互 的 网 络 系统 中 的 多 台 服 务 器 上 安装 一 个 或 多 个 相应 
的 负载 均衡 软件 来 实现 的 一 种 均衡 负载 技术 。 软 件 可 以 很 方便 地 安装 在 服务 器 上 ， 并 且 实 现 一 
定 的 均衡 负载 功能 。 软 件 负载 均衡 技术 配置 简单 、 操 作 也 方便 ， 最 重要 的 是 成 本 很 低 。 


硬件 负载 均衡 是 指 在 多 台 服 务 器 间 安 装 相 应 的 负载 均衡 设备 ， 也 就 是 负载 均衡 器 (如 F5) 
来 完成 均衡 负载 技术 ， 与 软件 负载 均衡 技术 相 比 ， 能 达到 更 好 的 负载 均衡 效果 。 由 于 硬件 负载 
均衡 技术 需要 额外 增加 负载 均衡 器 ， 成 本 比较 高 ， 所 以 适用 于 流量 高 的 大 型 网 站 系统 。 


这 里 主要 讨论 的 是 如 何 有 效 地 对 RabbitMQ 集群 使 用 软件 负载 均衡 技术 ， 目 前 主流 的 方式 
有 在 客户 端 内 部 实现 负载 均衡 ， 或 者 使 用 HAProxy、LVS 等 负载 均衡 软件 来 实现 。 
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11.2.1 ”客户 端 内 部 实现 负载 均衡 





对 于 RabbitMQ 而 言 可 以 在 客户 端 连接 时 简单 地 使 用 负载 均衡 算法 来 实现 负载 均衡 。 负 载 
均衡 算法 有 很 多 种 ， 主 流 的 有 以 下 几 种 。 


1. 轮 询 法 
将 请 求 按 顺序 轮流 地 分 配 到 后 端 服 务 器 上 ， 它 均衡 地 对 待 后 端的 每 一 台 服 务 器 ， 而 不 关心 
服务 器 实际 的 连接 数 和 当前 的 系统 负载 。 


如 代码 清单 11-6 所 示 ， 如 果 多 个 客户 端 需要 连接 到 这 个 有 3 个 节点 的 RabbitMQ 集群 ， 可 
以 调用 RoundRobin. Wafer es Lai iine wat ai 


代码 清单 11-6 轮 询 法 


public class RoundRobin ( 
private static List«String» list = new ArrayList«String»()(í 
add("192.168.0.2"); 
add["192.168.0.3"); 
add ("192.168.0.4"); 
}}; 
private static int pos = 0; 
private static final Object lock = new Object(); 
public static String getConnectionAddress()í 
String ip = null; 
synchronized (lock) { 
ip = list.get(pos); 
if (**pos >= list.size()) ( 
pos = 0; 
} 





} 


return ip; 


} 


2. 加 权 轮 询 法 


不 同 的 后 端 服务 器 的 配置 可 能 和 当前 系统 的 负载 并 不 相同 , 因此 它们 的 抗 压 能 力也 不 相同 。 
给 配置 高 、 负 载 低 的 机 器 配置 更 高 的 权重 ， 让 其 处 理 更 多 的 请 求 ， 而 配置 低 、 负 载 高 的 集群 ， 
给 其 分 配 较 低 的 权重 ， 降 低 其 系统 负载 ， 加 权 轮 询 能 很 好 地 处 理 这 一 问题 ， 并 将 请 求 顺序 和 权 
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重 分 配 到 后 端 。 


3. 随机 法 


通过 随机 算法 ， 根 据 后 端 服 务 器 的 列表 大 小 值 来 随机 选取 其 中 的 一 台 服 务 器 进行 访问 。 由 
概率 统计 理论 可 以 得 知 ， 随 着 客户 端 调用 服务 端的 次 数 增多 ， 其 实际 效果 越 来 越 接近 于 平均 分 
配 调 用 量 到 后 端的 每 一 台 服务 器 ， 也 就 是 轮 询 的 结果 。 对 应 的 示例 如 代码 清单 11-7 所 示 。 





public class RandomAccess ( 

private static List«String» list = new ArrayList«String»()(( 
&dd("192.168,0.2"); 
add("192.168.0.3"); 
add("192.168.0.4"); 

)n 

public static String getConnectionAddress()( 
Random random - new Random(); 
int pos = random.nextInt(list.size()); 
return list.get (pos); 

} 


4. 加 权 随机 法 


与 加 权 轮 询 法 一 样 ， 加 权 随 机 法 也 根据 后 端 机 器 的 配置 、 系 统 的 负载 分 配 不 同 权重 。 不 同 
的 是 ， 它 按照 权重 随机 请 求 后 端 服务 器 ， 而 非 顺 序 。 


5. 源 地 址 哈 希 法 


源 地 址 哈 希 的 思想 是 根据 获取 的 客户 端 卫 地 址 ， 通 过 哈 希 函数 计算 得 到 的 一 个 数值 ， 用 该 
数值 对 服务 器 列表 的 大 小 进行 取 模 运算 ， 得 到 的 结果 便 是 客户 端 要 访问 服务 器 的 序号 。 采 用 源 
地 址 哈 希 法 进行 负载 均衡 ， 同 一 IP 地 址 的 客户 端 ， 当 后 端 服 务 器 列表 不 变 时 ， 它 每 次 都 会 映射 
到 同一 台 后 端 服务 器 进行 访问 。 对 应 的 示例 如 代码 清单 11-8 所 示 。 





public class IpHash ( 
private static List«String» list = new ArrayList«String»()(( 
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add("192.168.0.2"); add("192.168.0.3"); add("192.168.0.4"); 
DE 
public static String getConnectionAddress() throws UnknownHostException { 
int ipHashCode - 
InetAddress.getLocalHost().getHostAddress ().hashCode(); 
int pos = ipHashCode $ list.size(); 
return list.get (pos); 
} 


6. 最 小 连接 数 法 

最 小 连接 数 算法 比较 灵活 和 智能 ， 由 于 后 端 服务 器 的 配置 不 尽 相同 ， 对 于 请 求 的 处 理 有 块 
有 慢 ， 它 根据 后 端 服务 器 当前 的 连接 情况 ， 动 态 地 选取 其 中 当前 积压 连接 数 最 少 的 一 台 服 务 器 
来 处 理 当前 的 请 求 ， 尽 可 能 地 提高 后 端 服 务 的 利用 效率 ， 将 负载 合理 地 分 流 到 每 一 台 服 务 器 。 

有 关于 加 权 轮 询 法 、 加 权 随 机 法 和 最 小 连接 数 法 的 实现 也 并 不 复杂 ， 这 里 就 留 给 读者 自己 
动手 实践 一 下 。 


HAProxy 提供 高 可 用 性 、 负 载 均衡 及 基于 TCP 和 HTTP 应 用 的 代理 ， 支 持 虚拟 主机 ， 它 是 
免费 、 快 速 并 且 可 靠 的 一 种 解决 方案 ， 包 括 Twitter, Reddit, StackOverflow, GitHub 在 内 的 多 
家 知名 互联 网 公司 在 使 用 。HAProxy 实现 了 一 种 事件 驱动 、 单 一 进程 模型 ， 此 模型 支持 非常 大 
的 并 发 连接 数 。 


1. 安装 HAProxy 


首先 需要 去 HAProxy 的 官网 下 载 HAProxy 的 安装 文件 ， 目 前 最 新 的 版 本 为 
haproxy-1.7.8.tar.gz。 下 载 地 址 为 http://www.haproxy.org/#down， 相 关 文 档 地 
址 为 http://www.haproxy.org/#docl.7。 


将 haproxy-1.7.8.tar.gz 复制 至 /opt 目录 下 ， 与 RabbitMQ 存放 在 同一 个 目录 中 ， 
之 后 进行 解压 缩 : 
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[root@nodel opt]# tar zxvf haproxy-1.7.8.tar.gz 


将 源码 解压 之 后 ， 需 要 运行 make 命令 来 将 HAProxy 编译 为 可 执行 程序 。 在 执行 make 之 
前 需要 先 选择 目标 平台 ， 通 常 对 于 UNIX 系 的 操作 系统 可 以 选择 TARGET=generic。 下 面 是 
详细 操作 : 


[root@nodel opt]# cd haproxy-1.7.8 
[root@nodel haproxy-1.7.8]# make TARGET-generic 
gcc -Iinclude -Iebtree -Wall -02 -g -fno-strict-aliasing 
-Wdeclaration-after-statement -fwrapv 
-DTPROXY -DENABLE POLL 
-DCONFIG HAPROXY VERSION=\"1.7.8\" 
-DCONFIG HAPROXY DATE-N"2017/07/07N" N 
-DBUILD TARGET-'"generic"' V : 
-DBUILD ARCH-'""' VN 
-DBUILD CPU-'"generic"' V 
-DBUILD CC-'"gcc"' \ 
-DBUILD CFLAGS-'"-O2 -g -fno-strict-aliasing -Wdeclaration-after-statement 
-fwrapv"' \ 
-DBUILD OPTIONS-'""' V 
-c -o src/haproxy.o src/haproxy.c 
gcc -Iinclude -Iebtree -Wall -02 -g -fno-strict-aliasing 
-Wdeclaration-after-statement -fwrapv... 


gcc -g -o haproxy src/haproxy.o src/base64.0 src/protocol.o src/uri auth.o ... 


编译 完 目录 下 有 名 为 “haproxy” 的 可 执行 文件 。 之 后 在 /etc/profile 中 加 入 haproxy 
的 路 径 ， 内 容 如 下 : 


export PATH=$PATH:/opt/haproxy-1.7.8/haproxy 


最 后 执行 source/etc/profile 让 此 环境 变量 生效 。 


2. 配置 HAProxy 


HAProxy 使 用 单一 配置 文件 来 定义 所 有 属性 , 包括 从 前 端 IP 到 后 端 服务 器 。 代 码 清单 11-9 
展示 了 用 于 3 个 RabbitMQ 节点 组 成 集群 的 负载 均衡 配置 。 


配置 相关 环境 说 明 如 下 所 述 。 
4 HAProxy 主机 : 192.168.0.9 5671. 


<%  RabbitMQ 1: 192.168.02 5672. 
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令 RabbitMQ 2: 192.168.03 5672. 


* RabbitMQ 3: 192.168.04 5672. 





# 全 局 配置 


global 






# 日 志 输出 配置 ， 所 有 日 志 都 记录 在 本 机 ， 通 过 localo 输出 
log 127.0.0.1 local0 info 

# 最 大 连接 数 

maxconn 4096 

# 改 变 当前 的 工作 目录 

chroot /opt/haproxy-1.7.8 

# 以 指定 的 UID 运行 naproxy 进程 

uid 99 

# 以 指定 的 GID 运行 haproxy 进程 

gid 99 

# 以 守护 进程 方式 运行 haproxy #debug #quiet 
daemon 

fdebug 

# 当 前 进程 pid 文件 

pidfile /opt/haproxy-1.7.8/haproxy.pid 


# 默 认 配 置 


defaults 


# 应 用 全 局 的 日 志 配置 

log global 

# 默 认 的 模式 mode(tcplhttplhealth) 
#TCP 是 4 层 ，HTTP 是 7 层 ，health 只 返回 OK 
mode tcp 

# 日 志 类 别 tcplog 

option tcplog 

# 不 记录 健康 检查 日 志 信息 

option dontlognull 

#3 次 失败 则 认为 服务 不 可 用 

retries 3 

# 每 个 进程 可 用 的 最 大 连接 数 

maxconn 2000 

# 连 接 超时 

timeout connect 5s 

# 客 户 端 超时 

timeout client 120s 

# 服 务 端 超时 


timeout server 120s 


# 绑 定 配置 
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listen rabbitmq cluster :5671 
# 配 置 TCP 模式 
mode tcp 
# 简 单 的 轮 询 
balance roundrobin 
#RabbitMO 集群 节点 配置 
server rmq nodel 192.168.0.2:5672 check inter 5000 rise 2 fall 3 weight 1 
server rmq node2 192.168.0.3:5672 check inter 5000 rise 2 fall 3 weight 1 
server rmq node3 192.168.0.4:5672 check inter 5000 rise 2 fall 3 weight 1 


#haproxy 监控 页 面 地 址 
listen monitor :8100 
mode http 
option httplog 
stats enable 
stats uri /stats 
stats refresh 5s 


在 前 面 的 配置 中 “listen rabbitmq cluster bind 192.168.0.9.5671” 定 义 了 
客户 端 连接 IP 地 址 和 端口 号 。 这 里 配置 的 负载 均衡 算法 是 roundrobin， 注 意 roundrobin 是 加 权 
轮 询 。 

和 RabbitMQ 最 相关 的 是 “server rmq nodel 192.168.0.2:5672 check inter 
5000 rise 2 fall 3 weight 1” 此 类 型 的 3 条 配置 ， 它 定义 了 RabbitMQ 服务 的 负载 均 
衡 细 节 ， 其 中 包含 6 个 部 分 。 


(1) server «name»: 定义 RabbitMQ 服务 的 内 部 标识 ， 注 意 这 里 的 “rmq_node1” 是 指 
包含 有 含义 的 字符 串 名 称 ， 不 是 指 RabbitMQ 的 节点 名 称 。 


(2) <ip>:<port>: 定义 RabbitMQ 服务 连接 的 卫 地 址 和 端口 号 。 
(3) check inter «value»: 定义 每 隔 多 少 毫秒 检查 RabbitMQ 服务 是 否 可 用 。 


(4) rise «value»: 定义 RabbitMQ 服务 在 发 生 故 障 之 后 ， 需 要 多 少 次 健康 检查 才能 被 
再 次 确认 可 用 。 


(5) fall «value»: 定义 需要 经 历 多 少 次 失败 的 健康 检查 之 后 ，HAProxy 才 会 停止 使 用 
此 RabbitMQ 服务 。 


(6) weight <value>: 定义 当前 RabbitMQ 服务 的 权重 。 
代码 清单 11-9 中 最 后 一 段 配置 定义 的 是 HAProxy 的 数据 统计 页 面 。 数 据 统计 页 面包 含 各 个 
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服务 节点 的 状态 、 连 接 、 负 载 等 信息 。 在 调用 haproxy -f haproxy.cfg 命令 运行 HAProxy 
服务 之 后 , 可 以 在 浏览 器 上 输入 http://192.168.0.9:8100/stats 来 加 载 相 关 的 页 面 , 如 图 11-11 所 示 。 


HAProxy version 1.5.2, released 2014/07/12 


Statistics Report for pid 31411 


> General process information 
fe active UP backup UP 
mkA passet, nbproc = 1) actve UP, going down — backup UP, going down 
wee T — active DOWN, going up ueni omg up 
, maxpipes = active or backup DOWN | [not checked 
= 0/0, conn rate = 1/sec active or backup DOWN sodio (MAINT) 
active or backup SOFT STOPPED for maintenance 
"NOLB''ORAIN' = UP with load-balancing disabled 


Toi |o] 
wei s ol -| ol -ol Toot | 


lmq_no 
med His Ee sr LESER o8 7 = 
| [ ol 90 








图 1 11-11 HAProxy 的 数据 统计 页 面 


11.2.3 ”使 用 Keepalived 实现 高 可 靠 负 载 均衡 





试想 如 果 前 面 配 置 的 HAProxy 主机 192.168.0.9 突然 宕 机 或 者 网 卡 失效 ,那么 虽然 RabbitMQ 
集群 没有 任何 故障 ， 但 是 对 于 外 界 的 客户 端 来 说 所 有 的 连接 都 会 被 断 开 ， 结 果 将 是 灾难 性 的 。 
确保 负载 均衡 服务 的 可 靠 性 同样 显得 十 分 重要 。 这 里 就 需要 引入 Keepalived 工具 ， 它 能 够 通过 
自身 健康 检查 、 资 源 接管 功能 做 高 可 用 〔 双 机 热 备 )， 实 现 故障 转移 。 


Keepalived 采用 VRRP (Virtual Router Redundancy Protocol， 虚 拟 路 由 元 余 协议 )， 以 软件 
的 形式 实现 服务 的 热 备 功能 。 通 常情 况 下 是 将 两 台 Linux 服务 器 组 成 一 个 热 备 组 (Master 和 
Backup)， 同 一 时 间 内 热 备 组 只 有 一 台 主 服务 器 Master 提供 服务 ， 同 时 Master 会 虚拟 出 一 个 公 
用 的 虚拟 IP 地 址 ， 简 称 VIP。 这 个 VIP 只 存在 于 Master 上 并 对 外 提供 服务 。 如 果 Keepalived 
检测 到 Master 宕 机 或 者 服务 故障 , 备份 服务 器 Backup 会 自动 接管 VIP 并 成 为 Master,Keepalived 
将 原 Master 从 热 备 组 中 移 除 。 当 原 Master 恢 复 后 ,会 自动 加 入 到 热 备 组 , 默认 再 抢占 成 为 Master， 
起 到 故障 转移 的 功能 。 
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Keepalived 工作 在 OST 模型 中 的 第 3 层 、 第 4 层 和 第 7 层 。 


工作 在 第 3 层 是 指 Keepalived 会 定期 向 热 备 组 中 的 服务 器 发 送 一 个 ICMP 数据 包 来 判断 某 
台 服 务 器 是 否 故障 ， 如 果 故 障 则 将 这 台 服 务 器 从 热 备 组 移 除 。 


工作 在 第 4 层 是 指 Keepalived 以 TCP 端口 的 状态 判断 服务 器 是 否 故障 , 比如 检测 RabbitMQ 
的 5672 端口 ， 如 果 故 障 则 将 这 台 服 务 器 从 热 备 组 中 移 除 。 


工作 在 第 7 层 是 指 Keepalived 根据 用 户 设 定 的 策略 (通常 是 一 个 自 定义 的 检测 脚本 〉 判 断 
服务 器 上 的 程序 是 否 正常 运行 ， 如 果 故 障 将 这 台 服 务 器 从 热 备 组 移 除 。 


1. Keepalived 的 安装 


首先 需要 去 Keepalived 的 官网 下 载 安装 文件 ， 目 前 最 新 的 版 本 为 keepalived-1.3.5. 
tar .gz， 下 载 地 址 为 http://www.keepalived.org/download.html。 


将 keepalived-1.3.5.tar.gz 解压 并 安装 ， 详 细 步 又 如 下 : 


[root8nodel ~]# tar zxvf keepalived-1.3.5.tar.gz 

[root8nodel ~]# cd keepalived-1.3.5 

[rootQnodel keepalived-1.3.5]4 ./configure --prefix-/opt/keepalived --with- 
init-SYSV 

HE: (upstart|systemd|SYSV|SUSE|openrc) # 根 据 你 的 系统 选择 对 应 的 启动 方式 

[root(nodel keepalived-1.3.5]# make 

[root(nodel keepalived-1.3.5]f4 make install 


之 后 将 安装 过 后 的 Keepalived 加 入 系统 服务 中 ， 详 细 步 骤 如 下 注意 千 万 不 要 输 错 命 令 ): 


# 复 制 启动 脚本 到 /etc/init.d/ 下 

[root@nodel ~]# cp /opt/keepalived/etc/rc.d/init.d/keepalived /etc/init.d/ 

[root@nodel ~]# cp /opt/keepalived/etc/sysconfig/keepalived /etc/sysconfig 

[root@nodel ~]# cp /opt/keepalived/sbin/keepalived /usr/sbin/ 

[root@nodel ~]# chmod +x /etc/init.d/keepalived 

[root@nodel ~]# chkconfig --add keepalived 

[root@nodel ~]# chkconfig keepalived on 

#Keepalived 默认 会 读 取 /etc/keepalived/keepalived.conf 配置 文件 

[root@nodel ~]# mkdir /etc/keepalived 

[root@nodel ~]# cp /opt/keepalived/etc/keepalived/keepalived.conf 
/etc/keepalived/ 


1 OSI 模型 ， 即 开放 式 通 信 系统 互联 参考 模型 (Open System Interconnection,OSI/RM,Open Systems Interconnection Reference 
Model)， 是 国际 标准 化 组 织 ASO) 提出 的 一 个 试图 使 各 种 计算 机 在 世界 范围 内 互 连 为 网 络 的 标准 框架 ， 简 称 OSI。 


e 319 e 


RabbitMQ 实战 指南 


执行 完 之 后 就 可 以 使 用 如 下 命令 来 重启 、 启 动 、 关 闭 和 查看 keepalived 状态 : 


service keepalived restart 
service keepalived start 
service keepalived stop 
service keepalived status 


2. 配置 


在 安装 的 时 候 我 们 已 经 创建 了 /etc/keepalived 目录 ， 并 将 keepalived.conf 配置 
文件 复制 到 此 目录 下 , 如 此 Keepalived 便 可 以 读 取 这 个 默认 的 配置 文件 了 。 如 果 要 将 Keepalived 
与 前 面 的 HAProxy 服务 结合 起 来 需要 更 改 /etc/keepalived/keepalived.conf 这 个 配置 
文件 ， 在 此 之 前 先 来 看 看 本 次 配置 需要 完成 的 详情 及 目标 。 


如 图 11-12 所 示 , 两 台 Keepalived 服务 器 之 间 通 过 VRRP 进行 交互 , 对 外 部 虚拟 出 一 个 VIP 
为 192.168.0.10。Keepalived 与 HAProxy 部 署 在 同一 台 机 器 上 ， 两 个 Keepalived 服务 实例 匹配 
两 个 HAProxy 服务 实例 ， 这 样 通过 Keeaplived 实现 HAProxy 的 双 机 热 备 。 所 以 在 上 一 节 的 
192.168.0.9 的 基础 之 上 ， 还 要 再 部 署 一 台 HAProxy 服务 ，IP 地 址 为 192.168.0.8。 









192.168.0.3 192.168.0.4 





192.168.0.2 
Rabbi Cluster 






图 11-12 通过 VRRP 交互 
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整 条 调用 链 路 为 : 客户 端 通过 VIP 建立 通信 和 链 路 ; 通信 和 链 路 通过 Keeaplived 的 Master 节点 
路 由 到 对 应 的 HAProxy 之 上 ;HAProxy 通过 负载 均衡 算法 将 负载 分 发 到 集群 中 的 各 个 节点 之 上 。 
正常 情况 下 客户 端的 连接 通过 图 11-12 中 左 侧 部 分 进行 负载 分 发 。 当 Keepalived 的 Master 节点 
挂 掉 或 者 HAProxy 挂 掉 无 法 恢复 时 ，Backup 提升 为 Master， 客户 端的 连接 通过 图 11-12 PAM 
部 分 进行 负载 分 发 。 


接 下 来 我 们 要 修改 /etc/keepalived/keepalived.conf 文 件 ,在 Keepalived HJ Master 
上 配置 详情 如 下 : 


#Keepalived 配置 文件 
global defs { 
router id NodeA # 路 由 ID、 主 / 备 的 ID 不 能 相同 


) 

# 自 定义 监控 脚本 

vrrp script chk haproxy { 
script "/etc/keepalived/check haproxy.sh" 
interval 5 
weight 2 

) 

vrrp instance VI 1 ( 


state MASTER 4Keepalived 的 角色 。Master 表示 主 服 务 器 ， 从 服务 器 设置 为 BACKUP 


interface eth0 # 指 定 监 测 网 卡 

virtual router id 1 

priority 100 # 优 先 级 ，BACKUP 机 器 上 的 优先 级 要 小 于 这 个 值 
advert int 1 # 设 置 主 备 之 间 的 检查 时 间 ， 单 位 为 s 
authentication { # 定 义 验证 类 型 和 密码 


auth type PASS 
auth pass root123 

) 

track script { 
chk haproxy 

) 

virtual ipaddress { #VIP 地 址 ， 可 以 设置 多 个 : 
192.168.0.10 

} 

} 


Backup 中 的 配置 大 致 和 Master 中 的 相同 ,不 过 需要 修改 global defs{} 的 router_id,， 
比如 设置 为 “NodeB”， 其 次 要 修改 vrrp instance VI 1{} 中 的 state Jy “BACKUP”; 
最 后 要 将 priority 设置 为 小 于 100 的 值 ,注意 Master 和 Backup 中 的 virtual router id 
要 保持 一 致 。 下 面 简要 地 展示 一 下 Backup 的 配置 : 
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global defs ( 
router id NodeB 
} 


vrrp_script chk_haproxy { 


} 
vrrp_instance VI_1 { 
state BACKUP 
priority 50 
, en 
为 了 防止 HAProxy 服务 挂 掉 之 后 Keepalived 还 在 正常 工作 而 没有 切换 到 Backup 上 ， 所 以 
这 里 需要 编写 一 个 脚本 来 检测 HAProxy 服务 的 状态 。 当 HAProxy 服务 挂 掉 之 后 该 脚本 会 自动 
重启 HAProxy 的 服务 ， 如 果 不 成 功 则 关闭 Keepalived 服务 ， 如 此 便 可 以 切换 到 Backup 继续 工 
作 。 这 个 脚本 就 对 应 了 上 面 配置 vrrp script chk haproxy{} 中 的 script 对 应 的 值 ， 
/etc/keepalived/check haproxy.sh 的 内 容 如 下 所 示 〔( 记 得 添加 可 执行 权限 )。 


#!/bin/bash 

if [ $(ps -C haproxy --no-header | wc -1) -eq 0 ];then 
haproxy -f /opt/haproxy-1.7.8/haproxy.cfg 

Ru 

sleep 2 

if [ $(ps -C haproxy --no-header | wc -1) -eq 0 ];then 
service keepalived stop 

fi 


如 此 配置 好 之 后 , 使 用 service keepalived start 命令 启动 192.168.0.8 和 192.168.0.9 


中 的 Keepalived 服务 即 可 。 之 后 客户 端的 应 用 可 以 通过 192.168.0.10 这 个 IP 地 址 来 接 通 
RabbitMQ 服务 。 


3. 查看 Keepalived 运行 情况 


可 以 通过 tail -f /var/log/messages -n 200 命令 查看 相应 的 Keepalived 日 志 输 
tH. Master 启动 日 志 如 下 : 


Oct 4 23:01:51 nodel Keepalived[30553]: Starting Keepalived v1.3.5 (03/19,2017), 
git commit v1.3.5-6-g6fa32f2 

Oct 4 23:01:51 nodel Keepalived[30553]: Unable to resolve default script username 
'keepalived script' - ignoring 

Oct 4 23:01:51 nodel Keepalived[30553]: Opening file 
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'/etc/keepalived/keepalived.conf'. 

Oct 4 23:01:51 nodel Keepalived[30554]: Starting Healthcheck child process, 
pid-30555 

Oct 4 23:01:51 nodel Keepalived[30554]: Starting VRRP child process, pid-30556 

Oct 4 23:01:51 nodel Keepalived healthcheckers[30555]: Opening file 
'/etc/keepalived/keepalived.conf'. 

Oct 4 23:01:51 nodel Keepalived vrrp[30556]: Registering Kernel netlink reflector 

Oct 4 23:01:51 nodel Keepalived vrrp[30556]: Registering Kernel netlink command 
channel 

Oct 4 23:01:51 nodel Keepalived vrrp[30556]: Registering gratuitous ARP shared 
channel 

Oct 4 23:01:51 nodel Keepalived vrrp[30556]: Opening file 
'/etc/keepalived/keepalived.conf'. 

Oct 4 23:01:51 nodel Keepalived vrrp[30556]: VRRP Instance(VI 1) removing 
protocol VIPs. 

Oct 4 23:01:51 nodel Keepalived vrrp[30556]: SECURITY VIOLATION - scripts are 
being executed but script security not enabled. 

Oct 4 23:01:51 nodel Keepalived vrrp[30556]: Using LinkWatch kernel netlink 
reflector... 

Oct 4 23:01:51 nodel Keepalived vrrp[30556]: VRRP sockpool: [ifindex(2), 
proto(112), unicast(0), fd(10,11)] 

Oct 4 23:01:51 nodel Keepalived vrrp[30556]: VRRP Instance(VI 1) Transition to 
MASTER STATE 

Oct 4 23:01:52 nodel Keepalived vrrp[30556]: VRRP Instance(VI 1) Entering MASTER 
STATE 

Oct 4 23:01:52 nodel Keepalived vrrp[30556]: VRRP Instance(VI 1) setting 
protocol VIPs. 


Master 启动 之 后 可 以 通过 ip add show 命令 查看 添加 的 VIP 〈 加 粗 部 分 ，Backup 节点 是 
没有 VIP 的 ): 


[root(nodel ~]# ip add show y 
1: lo: «LOOPBACK,UP,LOWER UP» mtu 65536 qdisc noqueue state UNKNOWN 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 
inet 127.0.0.1/8 scope host 1o 
inet6 ::1/128 scope host 
valid lft forever preferred lft forever 
2: eth0: «BROADCAST,MULTICAST,UP,LOWER UP» mtu 1450 qdisc pfifo fast state UP 
qlen 1000 
link/ether fa:16:3e:5e:7a:f7 brd ff:ff:ff:ff:ff:ff 
inet 192.168.0.8/18 brd 10.198.255.255 scope global eth0 
inet 192.168.0.10/32 scope global ethO 
inet6 fe80::f816:3eff:fe5e:7af7/64 scope link 
valid lft forever preferred lft forever 


TE Master 节点 执行 service keepalived stop 模拟 异常 关闭 的 情况 ， 观 察 Master 的 
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日 志 : 


Oct 4 22:58:32 nodel Keepalived[27609]: Stopping 

Oct 4 22:58:32 nodel Keepalived vrrp[27611]: VRRP Instance(VI 1) sent 0 priority 

Oct 4 22:58:32 nodel Keepalived vrrp[27611]: VRRP Instance(VI 1) removing 
protocol VIPs. 

Oct 4 22:58:32 nodel Keepalived healthcheckers[27610]: Stopped 

Oct 4 22:58:33 nodel Keepalived vrrp[27611]: Stopped 

Oct 4 22:58:33 nodel Keepalived[27609]: Stopped Keepalived v1.3.5 (03/19,2017), 
git commit v1.3.5-6-g6fa32f2 

Oct 4 22:58:34 nodel ntpd[1313]: Deleting interface #13 eth0, 192.168.0.104$123, 
interface stats: received-0, sent-0, dropped-0, active time-532 secs 

Oct 4 22:58:34 nodel ntpd[1313]: peers refreshed 


对 应 的 Master 上 的 VIP 也 会 消失 : 


[root@nodel ~]# ip add show 
1: lo: «LOOPBACK,UP,LOWER UP» mtu 65536 qdisc noqueue state UNKNOWN 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 
inet 127.0.0.1/8 scope host lo 
inet6 ::1/128 scope host 
valid lft forever preferred lft forever 
2: eth0: «BROADCAST,MULTICAST,UP,LOWER UP» mtu 1450 qdisc pfifo fast state UP 
qlen 1000 
link/ether fa:16:3e:5e:7a:f7 brd ff:ff:ff:ff:ff:ff 
inet 192.168.0.8/18 brd 10.198.255.255 scope global eth0 
inet6 fe80::f816:3eff:fe5e:7a£7/64 scope link 
valid lft forever preferred lft forever 


Master 关闭 后 ，Backup 会 提升 为 新 的 Master， 对 应 的 日 志 为 : 


Oct 4 22:58:15 node2 Keepalived vrrp[2352]: VRRP Instance(VI 1) Transition to 
MASTER STATE 

Oct 4 22:58:16 node2 Keepalived vrrp[2352]: VRRP Instance(VI 1) Entering MASTER 
STATE 

Oct 4 22:58:16 node2 Keepalived vrrp[2352]: VRRP Instance(VI 1) setting protocol 
VIPS. 


可 以 看 到 新 的 Master 节点 上 虚拟 出 了 VIP， 如 下 所 示 。 


[root@node2 ~]# ip add show 

1: lo: «LOOPBACK,UP,LOWER UP» mtu 65536 qdisc noqueue state UNKNOWN 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 | 
inet 127.0.0.1/8 scope host lo 
inet6 ::1/128 scope host 

valid lft forever preferred lfr forever 

2: eth0: «BROADCAST,MULTICAST,UP,LOWER UP» mtu 1450 qdisc pfifo fast state UP 

Glen 1000 
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link/ether fa:16:3e:23:ac:ec brd ff:ff:ff:ff:ff:ff 
inet 192.168.0.9/18 brd 10.198.255.255 scope global eth0 
inet 192.168.0.10/32 scope global eth0 
inet6 fe80::f816:3eff:fe23:acec/64 scope link 
valid lft forever preferred lft forever 


Keeaplived 的 出 现 让 HAProxy 的 负载 均衡 服务 更 加 可 靠 。 如 果 想 要 追求 要 更 高 的 可 靠 性 ， 
可 以 加 入 多 个 Backup 角色 的 Keepalived 节点 来 实现 一 主 多 从 的 多 机 热 备 ,当然 这 样 会 提升 硬件 
资源 的 成 本 , 该 如 何 抉择 需要 更 细致 的 考量 , 一 般 情况 下 双 机 热 备 的 配备 已 足够 满足 应 用 需求 。 


11.2.4 ”使 用 Keepalived+LVS 实现 负载 均衡 


负载 均衡 的 方案 有 很 多 , 适合 RabbitMQ 使 用 的 除 HAProxy 外 还 有 LVS。LVS Æ Linux Virtual 
Server 的 简称 ， 也 就 是 Linux 虚拟 服务 器 ， 是 一 个 由 章 文山 博士 发 起 的 自由 软件 项 目 ， 它 的 官 
方 站 点 是 www.linuxvirtualserver.org. 现在 LVS 已 经 是 Linux 标准 内 核 的 一 部 分 , 在 Linux2.6.32 
内 核 以 前 ， 使 用 LVS 时 必须 要 重新 编译 内 核 以 支持 LVS 功能 模块 ， 但 是 从 Linux2.6.32 内 核 以 
后 , 已 经 完全 内 置 了 LYVS 的 各 个 功能 模块 , 无 须 给 内 核 打 任何 补丁 ,可 以 直接 使 用 LVS 提供 的 
各 种 功能 。 


LVS 是 4 层 负载 均衡 ， 也 就 是 说 建立 在 OSI 模型 的 传输 层 之 上 。LVS 支持 TCP/UDP 的 负载 
均衡 ， 相 对 于 其 他 高 层 负载 均衡 的 解决 方案 ， 比 如 DNS 域名 轮流 解析 、 应 用 层 负载 的 调度 、 客 
户 端的 调度 等 ， 它 是 非常 高 效 的 。LVS 自从 1998 年 开始 ， 发 展 到 现在 已 经 是 一 个 比较 成 熟 的 技 
术 项 目 了 。 可 以 利用 LVS 技术 实现 高 可 伸缩 的 、 高 可 用 的 网 络 服务 。 例 如 ，WWW 服务 、Cache 
服务 、DNS 服务 、FTP 服务 、MAIL 服务 、 视 频 / 音 频 点 播 服务 等 。 有 许多 比较 著名 网 站 和 组 织 都 
在 使 用 LVS 架设 的 集群 系统 。 例 如 ，Linux 的 门户 网 站 (www.linux.com)、 向 RealPlayer 提供 音 
频 视 频 服务 而 闻名 的 Real 公司 《www.real.com)、 全 球 最 大 的 开源 网 站 Csourceforge.net) 等 。 


LVS 主要 由 3 部 分 组 成 。 


€ 负载 调度 器 (Load Balancer/Director): 它 是 整个 集群 对 外 面 的 前 端 机 ,负责 将 客户 的 请 
求 发 送 到 一 组 服务 器 上 执行 ， 而 客户 认为 服务 是 来 自 一 个 他 地 址 (VIP) 上 的 。 


信 服务 器 池 〈Server Pool/RealServer): 一 组 真正 执行 客户 端 请 求 的 服务 器 ， 如 RabbitMQ 
服务 器 。 
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个 


共享 存储 《〈Shared Storage): 它 为 服务 器 池 提 供 一 个 共享 的 存储 区 ， 这 样 很 容易 使 服务 
器 池 拥 有 相同 的 内 容 ， 提 供 相同 的 服务 。 


目前 LVS 的 负载 均衡 方式 也 分 为 三 种 。 


个 


VS/NAT: Virtual Server via Network Address Translation 的 简称 。VS/NAT 是 一 种 最 简单 
的 方式 ， 所 有 的 RealServer 只 需要 将 自己 的 网 关 指 向 Director 即 可 。 客 户 端 可 以 是 任意 
的 操作 系统 ， 但 此 方式 下 一 个 Director 能 够 带动 的 RealServer 比较 有 限 。 


VS/TUN: Virtual Server via IP Tunneling 的 简称 。IP 隧道 (IP Tunneling) 是 将 一 个 卫 
报 文 封装 再 另 一 个 IP 报 文 的 技术 , 这 可 以 使 目标 为 一 个 人 P 地 址 的 数据 报 文 能 够 被 封装 
和 转发 到 男 一 个 IP 地 址 。IP 隧道 技术 也 可 以 称 之 为 IP 封装 技术 AP encapsulation). 


VS/DR: 即 Virtual Server via Direct Routing 的 简称 。VS/DR 方式 是 通过 改写 报 文中 的 
MAC 地 址 部 分 来 实现 的 。Director 和 RealServer 必须 在 物理 上 有 一 个 网 卡通 过 不 间断 
的 局 域 网 相连 。RealServer 上 绑 定 的 VIP 配置 在 各 自 Non-ARP 的 网 络 设备 上 《如 lo 或 
tunl), Director 的 VIP 地 址 对 外 可 见 , 而 RealServer 的 VIP 对 外 是 不 可 见 的 。RealServer 
的 地 址 既 可 以 是 内 部 地 址 ， 也 可 以 是 真实 地 址 。 


对 于 LVS 而 言 配合 Keepalived 一 起 使 用 同样 可 以 实现 高 可 靠 的 负载 均衡 ， 对 于 图 11-12 来 
说 ，LVS 可 以 完全 替代 HAProxy 而 其 他 内 容 可 以 保持 不 变 。LVS 不 需要 额外 的 配置 文件 ， 直 接 
集成 在 Keepalived 的 配置 文件 之 中 。 修 改 /etc/keepalived/keepalived.conf 文件 内 容 


如 下 : 


#Keepalived 配置 文件 (Master) 
global defs ( 


) 


router id NodeA # 路 由 ID、 主 / 备 的 ID 不 能 相同 


vrrp instance VI 1 ( 
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state MASTER #Keepalived 的 角色 。Master 表示 主 服 务 器 ， 从 服务 器 设置 为 BACKUP 


interface eth0 # 指 定 监 测 网 卡 

virtual router id 1 

priority 100 HREH, BACKUP 机 器 上 的 优先 级 要 小 于 这 个 值 
advert int 1 # 设 置 主 备 之 间 的 检查 时 间 ， 单 位 为 s 
authentication { # 定 义 验证 类 型 和 密码 


auth type PASS 
auth pass root123 
) 


track script ( 
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chk haproxy 

} 

virtual_ipaddress { #VIP 地 址 ， 可 以 设置 多 个 : 
192.168.0.10 

) 


virtual server 192.168.0.10 5672 ( # 设 置 虚 拟 服务 器 


delay loop 6 # 设 置 运行 情况 检查 时 间 ， 单 位 是 秒 

# 设 置 负载 调度 算法 ， 共 有 rr, wrr lce, wle, lblc, lblcr, dh, sh ìà 8 种 
lb algo wrr # 这 里 是 加 权 轮 询 
lb kind DR # 设 置 LVS 实现 的 负载 均衡 机 制 方式 vs / DR 


# 指 定 在 一 定 的 时 间 内 来 自 同一 IP 的 连接 将 会 被 转发 到 同一 RealServer 中 


persistence timeout 50 


protocal TCP # 指 定 转发 协议 类 型 ， 有 TCP 和 UDP 两 种 


HX real server Hl LVS 的 三 大 部 分 之 一 的 RealServer， 这 里 特 指 RabbitMo 的 服务 


real server 192.168.0.2 5672 ( # 配 置 服务 节点 
weight 1 # 配 置 权重 
TCP CHECK | 
connect timeout 3 
nb get retry 3 
delay before retry 3 
connect port 5672 


) 
real server 192.168.0.3 5672 ( 
weight 1 
TCP CHECK ( 
connect timeout 3 
nb get retry 3 
delay before retry 3 
connect port 5672 


) 
real server 192.168.0.4 5672 ( 
weight 1 
TCP CHECK ( 
connect timeout 3 
nb get retry 3 
delay before retry 3 
connect port 5672 


) 


$73 RabbitMQ 的 RabbitMQ Management 插件 设置 负载 均衡 
virtual server 192.168.0.10 15672 ( 


delay loop 6 


e 327 * 


RabbitMQ 实战 指南 


lb algo wrr 
lb kind DR 
persistence timeout 50 
protocal TCP 
real server 192.168.0.2 15672 { 
weight 1 
TCP CHECK ( 
connect timeout 3 
nb get retry 3 
delay before retry 3 
connect port 15672 
} 
) 
real server 192.168.0.3 15672 { 
weight 1 
TCP CHECK ( 
connect timeout 3 
nb get retry 3 
delay before retry 3 
connect port 15672 
) 
} 
real server 192.168.0.4 15672 { 
weight 1 
TCP CHECK ( 
connect timeout 3 
nb get retry 3 
delay before retry 3 
connect port 15672 





) 


对 于 Backup 的 配置 可 以 参考 前 一 节 中 的 相应 配置 。 在 LVS 和 Keepalived 环境 里 面 ，LVS 
主要 的 工作 是 提供 调度 算法 ， 把 客户 端 请 求 按照 需求 调度 在 RealServer 中 ，Keepalived 主要 的 
工作 是 提供 LVS 控制 器 的 一 个 元 余 , 并 且 对 RealServer 进行 健康 检查 , 发 现 不 健康 的 RealServer 
就 把 它 从 LVS 集群 中 剔除 ，RealServer 只 负责 提供 服务 。 


通常 在 LVS 的 VS/DR 模式 下 需要 在 RealServer 上 配置 VIP。 原 因 在 于 当 LVS 把 客户 端的 包 
转发 给 RealServer 时 ， 因 为 包 的 目的 外 Hihii VIP, WHR RealServer 收 到 这 个 包 后 发 现 包 的 目的 地 
址 不 是 自己 系统 的 全， 会 认为 这 个 包 不 是 发 给 自己 的 ， 就 会 丢弃 这 个 包 ， 所 以 需要 将 这 个 IP 地 址 
绑 定 到 网 卡 下 。 当 发 送 应 答 包 给 客户 端 时 ，RealServer 就 会 把 包 的 源 和 目的 地 址 调换 ， 直 接 回 复 给 
客户 端 。 下 面 为 所 有 的 RealServer 的 lo:0 网 卡 创建 启动 脚本 (vim /opt/realserver.sh) 绑 定 
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VIP 地 址 ， 详 细 内 容 如 下 : 


#!/bin/bash 
VIP=192.168.0.10 
/etc/rc.d/init.d/functions 


case "$1" in 


start) 
/sbin/ifconfig 10:0 $VIP netmask 255.255.255.255 broadcast $VIP 
/Sbin/route add -host SVIP dev 1o:0 
echo "1" »/proc/sys/net/ipv4/conf/lo/arp ignore 
echo "2" »/proc/sys/net/ipv4/conf/lo/arp announce 
echo "1" »/proc/sys/net/ipv4/conf/all/arp ignore 
echo "2" »/proc/sys/net/ipv4/conf/all/arp announce 
sysctl -p »/dev/null 2>&1 
echo "RealServer Start Ok" 
stop) 
/sbin/ifconfig 10:0 down 
/Sbin/route del -host $VIP dev 1o:0 
echo "0" »/proc/sys/net/ipv4/conf/lo/arp ignore 
echo "0" »/proc/sys/net/ipv4/conf/lo/arp announce 
echo "0" »/proc/sys/net/ipv4/conf/all/arp ignore 
echo "0" »/proc/sys/net/ipv4/conf/all/arp announce 
status) 
islothere- /sbin/ifconfig 1o:0 | grep $VIP | wc -1` 
isrothere-' netstat -rn | grep "lo:0"|grep $VIP | wc -1' 
if [ $islothere -eq 0 ] 
then 
if [ S$isrothere -eq 0 ] 
then 
echo "LVS of RealServer Stopped." 
else 
echo "LVS of RealServer Running." 
fi 
else 
echo "LVS of RealServer Running." 
fi 
: 
echo "Usage:$0(start|stop)" 
exit 1 
esac 


注意 上 面 绑 定 VIP 的 掩 码 是 255.255.255.255, 说 明 广 播 地 址 是 其 自身 ,那么 它 就 不 会 将 ARP 
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发 送 到 实际 的 自己 该 属于 的 广播 域 了 ， 这 样 防止 与 LVS 上 的 VIP 冲突 进而 导致 P 地 址 冲突 。 
Jj/opt/realserver.sh 文件 添加 可 执行 权限 后 ， 运 行 /opt/realserver .sh start 命 
令 之 后 可 以 通过 ip add show 命令 查看 lo:0 网 卡 的 状态 ， 注 意 与 Keepalived 节点 的 网 卡 状态 
进行 区 分 。 
[root@nodel keepalived]# ip add show 
1: lo: «LOOPBACK,UP,LOWER UP» mtu 65536 qdisc noqueue state UNKNOWN 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 
inet 127.0.0.1/8 scope host lo 
inet 192.168.0.10/32 brd 10.198.197.74 scope global 1o:0 
inet6 ::1/128 scope host 
valid lft forever preferred lft forever 
2: eth0: «BROADCAST,MULTICAST,UP,LOWER UP» mtu 1450 qdisc pfifo fast state UP 
qlen 1000 
link/ether fa:16:3e:5e:7a:f7 bra ff:ff:ff:ff:ff:ff 
inet 192.168.0.2/18 brd 10.198.255.255 scope global eth0 
inet6 fe80::f816:3eff:fe5e:7a£7/64 scope link 
valid lft forever preferred lft forever 


lL3 4wgE 


本 章 主要 探讨 的 是 RabbitMQ 的 两 个 扩展 : 消息 追踪 和 负载 均衡 。 消 息 追 踪 可 以 有 效 地 定 
位 消息 丢失 的 问题 :是 在 发 送 端 , 还 是 在 服务 端 , 又 或 者 是 在 消费 端 ? 消息 追踪 主要 包含 Firehose 
和 rabbitmq tracing 插件 ， 任 意 开 启 一 个 都 会 耗费 服务 器 的 性 能 。 有 资料 表明 在 开启 
Firehose (EX rabbitmq tracing 插件 ) 时 ， 临 界 情况 能 耗费 服务 器 性 能 的 30% 一 40%， 故 不 
适合 在 正常 运行 环境 中 使 用 ， 只 是 作为 一 个 扩展 功能 方便 在 遇 到 问题 时 复 现 后 的 定位 。 负 载 均 
衡 本 身 属于 运 维 层面 ， 将 此 剥离 出 第 7 章 的 运 维 范 畴 是 因为 本 书 前 面 所 有 篇 幅 都 在 介绍 
RabbitMQ 本 身 的 功能 , 而 这 里 的 负载 均衡 指 的 是 服务 端 入 站 连接 的 负载 均衡 , 一 般 需 要 借助 第 
=J L.R.——HAProxy. Keepalived 和 LVS 来 实现 ， 故 视 作 扩展 之 用 。 有 关 RabbitMQ 的 扩展 还 
可 以 包含 Spring 与 RabbitMQ 的 整合 、Storm 与 RabbitMQ 的 整合 等 ， 由 于 篇 幅 所 限 ， 这 里 就 不 
多 做 介绍 ， 有 兴趣 的 读者 可 以 自行 查阅 相关 资料 。 
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附录 A ”集群 元 数据 信息 示例 


"rabbit version": "3.6.10"，// 集 群 节点 版 本 号 
"users": [// 用 户 信息 
"name": "guest", // 默 认 账 户 
"password hash": "3AxhftqgMnqa7ApWREm*PDOU7tL98iEi/SVefsM8gLqzrhbJX", 
"hashing algorithm": "rabbit password hashing sha256", 
"tags": "administrator" 


"name"; "root", 
"password hash": "dx8F8-*ylF/W3PTzzhbbqgo4UgBTzUCRVWMaStErFgW2W5iYTP", 
"hashing algorithm": "rabbit password hashing sha256", 


"tags": "administrator" 
) 
l]; 
"uvhosts": [ ( "name": "/" } Jy 
"permissions": [ 
( "user"; "root", "yhost":; "/", "configuxe": ".*'', 
"write": ".,*", traad m m y, 
f "user": "guest", 'vbhost": "/", "configure": "wm". 
"Write": "Ox", Tread" Tow" j 


Íz 
"parameters": [], 
"global parameters": [// 旧 一 点 的 版 本 没有 这 一 项 内 容 
( "name": "cluster name", "value": "rabbitG8nodel" } 
l; 
"policies": [// 策 略 
{ 


"vhost": wf "name": "pl", "pattern": WEN y "apply-to": "queues", 
"definition": ( "ha-mode": "exactly", "ha-params": 2, 
"ha-sync-mode": "automatic" }, 


"priority":.0 


} 
],// 分 界 点 ， 下 面 是 关键 的 队列 、 交 换 器 和 绑 定 关 系 的 元 数据 
"queues": [// 队 列 信息 
( "name": "queue3", "vhost": "/", "durable": true, 
"auto delete": false, "arguments": () ], 
( "name": "queuel", "vhost": "/", "durable": true, 
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l; 


"auto delete": false, "arguments": () ], 
"name" : "queue2" ” "ghost" : "mn T 
"durable"; Erue, rauto delete": farse, 
"arguments": ( 

"x-dead-letter-exchange": "exchange dlx", 


"x-message-ttl": 200000, 
"x-max-length": 100000 


"exchanges": [// 交 换 器 信息 


{ 


]; 


"name": "exchange", "vhost": "/", "type": "direct", 
"durable": true, "auto delete": false, 
"internal": false, "arguments": {} 


"name": "exchange2e", "vhost": "/", "type": "direct", 
"durable"; true, "auto delete": false, 
"internal": false, "arguments": {} 


"bindings": [// 绑 定 信息 ， 注 意 绑 定 有 两 种 ， 交 换 器 与 队列 绑 定 ， 交 换 器 与 交换 器 绑 定 


{ 
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"source": "exchange", "vhost": "/", "destination": "queuel", 
"destination type": "queue", 

"routing key": TEKILT, "arguments": f} 

"source": "exchange", "vhost": "/", "destination": "queue2", 
"destination type": "queue", 

"routing key": "rk2", "arguments": () 

"source": "exchange", "vhost": "/", "destination": "queue3", 
"destination type": "queue", 

"routing key": "rk3", "arguments": () 

"source": "exchange", "vhost": "/", "destination": "exchange2e", 
"destination type": "exchange", 

"routing key": "rk exchange", "arguments": {} 


附录 B /api/nodes 接口 详细 内 容 


curl -i -ü root:root123 -H "content-type:application/json" -X GET http:// 


localhost:15672/api/nodes 的 执行 结果 如 下 〈 单 节点 的 ): 
[ 


"partitions": [], 
"os pld™ "15015", 
"fd total": 1024, 
"sockets total": 829, 
"mem limit": 3301929779, 
"mem alarm": false, 
"disk free limit": 50000000, 
"disk free alarm": false, 
"proc total": 1048576, 
"rates mode": "basic", 
"uptime": 99563, 
"run queue": 0, 
"processors": 4, 
"exchange types": [ 
( "name": "fanout", 
"description": "AMQP fanout exchange, 
as per the AMQP specification", 
"enabled": true }, 
( "name": "headers", 
"description": "AMQP headers exchange, 
as per the AMQP specification", 
"enabled": true }, 
( "name": "topic", 
"description": "AMQP topic exchange, 
as per the AMQP specification", 
"enabled": true }, 
( "name": "direct", 
"description": "AMQP direct exchange, 
as per the AMQP specification", 
"enabled": true ) 
]; 
"auth mechanisms": [ 
( "name": "RABBIT-CR-DEMO", 
"description": "RabbitMQ Demo challenge-response 
authentication mechanism", 
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"enabled": false }, 

( "name": "PLAIN", 
"description": "SASL PLAIN authentication mechanism", 
"enabled": true ), 

( "name": "AMOPLAIN", 


"description": 


"OPid AMQPLAIN mechanism", 





"enabled": true ) 
l; 
"applications": [ 
( "name": "amqp client", "description": "RabbitMQ AMQP Client", 
"version"; "3.6.10" Yg 


// 篇 幅 限 制 ， 省 略 若干 与 监控 无 关 的 数据 
l, 


"contexts": [ { "description": "RabbitMQ Management", 
"path": "m. "port": "15672" į ] ? 
"log file": "/opt/rabbitmq/var/log/rabbitmq/rabbit8nodel.log", 


"sasl log file": 
"/lopt/rabbitmq/var/log/rabbitmg/rabbit(nodel-sasl.log", 

"db dir": "/opt/rabbitmq/var/lib/rabbitmqg/mnesia/rabbit(nodel", 

"config files": [ "/opt/rabbitmqg/etc/rabbitmg/rabbitmq.config 
(not found)" ], 

"net ticktime": 60, 

"enabled plugins": [ "rabbitmq management" ], 

"name": "rabbit8nodel", "type": "disc", 


"running": true, "mem used": 58328312, 


"mem used details": { "rate": -123492.8 ], 
"fd used": 57, 
"fü used deballs"s 4 "rate": -L n 


"sockets used": O0, 
"sockets used details": 
"proc used"; 326, 


Í "rate": 0 Jy 


"proc used details": ( "xate": =1 y, 
"disk free": 23734689792, 
"disk free details": { "rate": 0 ], 
"gc num"; 5320, 

"ge num details": f "rate": 19.4 P, 


"gc bytes reclaimed": 290549824, 


"gc bytes reclaimed details": { "rate": 278136 }, 
"context switches": 83470, 
"context switches details": ( "rate": 67.4 F, 


"lo read count” a 1; 
"io read count details": 
"io read bytes": 1, 


[I "rate": 0 ), 


"io read bytes details": ( "rate": O0 ], 
"io read avg time": 0.041, 
"io read avg time details": ( "rate": © ), 





"io write count': 0, 
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"io write count details"; [^ "rate"; Q }; 
"io write bytes": O0, 

"io write bytes details": { "rate": 0 ], 
"io write avg time": 0, 

"io write avg time details": { "rate": 0 ], 
"io sync count": 0; 

"io sync count details": f "rate": O0 ), 
"io sync avg time": O0, 

"io sync avg time details": ( "rate": 0 ], 
"io seek count": O0, 

"io seek count details": { "rate": 0 }; 
"io seek avg time": 0, 

"io seek avg time détails": { "rate": 0 ], 


"io reopen count": 0, 

"io reopen count sdetails": tf "rate": 0 }, 
"mnesia ram tx count": 16, 

"mnesia ram tx count details": ( "rate": O0 }, 
"mnesia disk tx count": 7, 


"mnesia disk tx count details": ( "rate": 0.2 }, 


"msg store read count": 0, 

"msg store read count details": ( "rate": 0 ], 
"msg store write count": 0, 

"msg store write count details": ( "rate": 0 ], 
"queue index journal write count": O0, 


"queue index journal write count details": { "rate": OQ ], 


"queue index write count": 0, 
"queue index write count details": ( "rate": 0 
"queue index read count": O0, 


"queue index read count details": { "rate": 0 }, 





"io file handle open attempt count": 11, 
"io file handle open attempt count details": { 





"rate": 


0 ), 


"io file handle open attempt avg time": 0.0528181818181818, 





"io file handle open attempt avg time details": 
"cluster links": [], 
"metrics gc queue length": { 
"connection closed": 0, 
"channel closed": 0, 
"consumer deleted": 0, 
"exchange deleted": 0, 
"queue deleted": 0, 
"vhost deleted": O0, 
"node node deleted": 0; 
"channel consumer deleted": 0 


{ 


"rate": 


0 


), 
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有 disc 节 点 










客户 端 连接 数 最 多 
,. Tabbitmactl stop app/rabbitmactl start_app( 推 荐 ) 
-| rabbitmqct! stop/rabbit-server -detached 


停止 其 他 分 区 中 的 所 有 节点 ， 然 后 再 启动 这 些 节点 。 如 果 此 
时 还 有 网 络 分 区 的 告警 ， 则 再 重启 信任 分 区 中 的 节点 以 去 除 











告警 
J 关闭 整个 集群 的 节点 ， 然 后 再 启动 每 一 个 节点 ， 这 里 需要 确 
保 你 启动 的 第 一 个 节点 在 你 信任 的 分 区 之 中 





自动 恢复 ， 在 rabbmq.config 中 配置。 duster_Parition handing pause minortyl 
cluster partition handling df 引 (pause if. all down, [nodes], ignore | autoheal) 


















(cluster partition handling, autoheal) 
" RU 
Et 了 发 生 分 区 时 不 做 任何 动作 








分 区 发 生 开始 时 《net_tick_timeout〉， 关 闭 "少数 派 " 分 区 中 的 
节点 





“少数 派 "分 区 是 指 小 于 等 于 集群 中 一 半 节 点 数 
分 区 判定 之 后 ， 启 动 关闭 的 节点 
对 等 分 区 的 情况 处 理 的 不 够 优雅 
分 区 之 后 ， 与 列表 中 的 任何 节点 不 能 内 部 通信 时 会 关闭 应 用 




















多 分 区 的 处 理 比 autoheal 的 优雅 

分 区 判定 之 后 会 挑选 获胜 分 区 
重启 非 获 胜 分 区 中 的 节点 
客户 端 连 按 数 


如 何 挑选 获胜 分 区 d 分 区 内 节点 数 
节点 名 称 字典 序 


pause-if-all down 1 难点， 受信 节点 的 选择 
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本 书 主要 内 容 : 


O RabbitMQ 的 基本 安装 与 使 用 方式 。 

6 RabbitMQ 的 基本 概念 ， 包 括 生产 者 、 消 费 者 、 交 换 器 、 队 列 、 绑 定 等 。 

© RabbitMQ 的 高 级 特性 ， 如 : TTL、 死 信 、 延 迟 队 列 、 优 先 级 队列 、RPC、 消 息 
持久 化 、 生 产 端 和 消费 端的 消息 确认 等 。 

O RabbitMQ 的 管理 、 配 置 、 运 维 。 

© RabbitMQ 的 存储 机 制 、 流 控 及 镜像 队列 的 原理 。 

Q 网 络 分 区 。 

© RabbitMQ 的 一 些 扩 展 内 容 。 
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